From: Davin McCall Date: Tue, 12 Jun 2018 17:20:25 +0000 (+0100) Subject: TODO: add planned features for next release. X-Git-Tag: v0.3.0~27 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=aeeefc8f20529de229715f3a7f4e7a380d4246e0;p=oweals%2Fdinit.git TODO: add planned features for next release. --- diff --git a/TODO b/TODO index 002f4a8..a3db9b0 100644 --- a/TODO +++ b/TODO @@ -1,6 +1,14 @@ For version 0.3.0: ------------------ -* (Not yet decided). +* Skippable services: if they terminate via ^C, treat as a successful startup. Allows + skipping filesystem checks. +* Provide better status information: + - whether a service failed to start (as opposed to just being STOPPED) + - directly, and how (error code? died to signal? timed out?) or + - due to a dependency. + - whether a service has acquired, or is waiting to acquire, the console + - whether service was skipped (via ^C/SIGINT) instead of started normally. +* Option to send signals to service process leader only (not to process group). For version 1.0: ---------------- @@ -14,12 +22,15 @@ For version 1.0: * A (perhaps limited) way(s) to modify a service description after it is loaded - eg add/remove dependencies, change properties. * Think about detecting runs-on-console dependency conflicts (i.e. if A runs-on-console and - B depends on A and runs-on-consle then B can never start). + B depends on A and runs-on-consle then B can never start)? + - Complicated if service descriptions can be altered after loading. Perhaps not necessary + if better status information can be provided. * Documentation must be complete (see section below). * Package-manager-friendly way to enable/disable services. Perhaps a service can specify a dependency file (with dependency type) where the file contains a list of service names, or if it is a directory, each filename within corresponds to a service that is a dependency. +* Proper support for socket activation? * Be able to boot and shutdown Linux and FreeBSD. For later: @@ -43,6 +54,13 @@ For later: But perhaps this really the responsibility of another daemon. * Allow running services with different resource limits, chroot, cgroups, namespaces (pid/fs/uid), etc +* Support chaining service output to another process (logger) input; if the + service dies the file descriptor of its stdout isn't closed and is reassigned + when the service is restarted, so that minimal output is lost. + - even more, it would be nice if a single logger process could be responsible + for receiving output from multiple services. This would require some kind of + protocol for passing new output descriptors to the logger (for when a + service starts). Even later / Maybe never: -------------------------