-For version 0.3.0:
+For version 0.9.0:
------------------
-* (Not yet decided).
-
-For version 1.0:
-----------------
-* Support S6-style startup notification (write to fd)
-* Man pages for all programs (done for dinit, not for dinitctl/shutdown/etc).
-* Write wtmp entry on startup (see simpleinit)
+* "chain-to" can result in an unbreakable loop if the chain is circular. Chained services should not be
+ started during shutdown to prevent this (also avoids a race condition where the chained service is left
+ running when everything else has shutdown).
+* Check that desired_state is getting set correctly. (Currently we don't decide whether a service
+ will restart until it stops...)
+* Add dinit command line option to run as pid 1 but not as system manager (i.e., in a container).
+ Currently dinit can be used as pid 1 in a container but it may try to shut down the system when
+ it terminates. (This results in a harmless warning, but is not ideal).
+
+For version 0.10.+:
+------------------
+* for non-system init, fail if the control socket exists, with option to override this and re-
+ create the socket instead (as system init does).
+* report process launch failure reason (stage & errno) via dinitctl.
+* Show "activated" state in "dinitctl list" output
+* Service description sanity checks:
+ - Service type not specified
+ - maybe default to 'internal' if command not specified
+ - if command specified but type not, report an error
+ - other checks?
+ - errors should also be reported by dinitcheck
+
+For version 1.0 (i.e. longer-term plans):
+-----------------------------------------
+* Service description parse errors should report line number
+* dinitcheck should perform lint checks - do named files exist? etc
+* Limit memory use by control connections. Currently clients can queue commands without limit.
+* Consider using mlockall (if system process).
+* Dinitctl command to get full status of a service.
* "triggered" service type: external process notifies Dinit when the service
has started. (maybe?)
+ - key thing is we want some way to eg mount filesystem once the disk comes up,
+ configure network when device comes up, etc, potentially relying an an external
+ tool/daemon.
* on shutdown, after repeated intervals with no activity, display information
about services we are waiting on (or, do this when prompted via ^C or C-A-D).
-* 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).
* 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.
-* Be able to boot and shutdown Linux and FreeBSD.
+* Proper support for socket activation?
+* Chaining of service process input/output?
+* Be able to boot and shutdown Linux and FreeBSD (or OpenBSD).
-For later:
-----------
+For later (post 1.0):
+---------------------
* On linux when running with PID != 1, write PID to /proc/sys/kernel/cad_pid so
that we still receive SIGINT from ctrl+alt+del (must be done after /proc is
mounted, possibly could be left to a service script)
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:
-------------------------
Documentation:
--------------
* Design philosophy/rationale document
-* Coding style guidelines
-
-* What's the best TERM setting? gogetty gives me "linux" but I think other variants may be
- better (eg "linux-c").
-
-* Figure out the ConsoleKit/logind / PolicyKit mess & how dinit needs to fit into it.
- * Consolekit/logind tracks "sessions". Provides a mechanism to mark a session starting,
- associates processes with sessions, provides calls to terminate sessions etc (why?!!)
- Can use environment variable or cgroups to track processes in a session.
- A PAM module exists to create/destroy sessions.
- * Consolekit/logind also allows for requesting shutdown, reboot, and inhibiting reboot
- (via dbus API).
- * "seats" are a set of input/output hardware (mouse/keyboard/monitor) on which a session
- can be run. You can have multiple sessions on a seat - one is in the foreground
- (eg linux virtual ttys implement multiple sessions on a single seat).
- Sessions can run without a seat (eg ssh session).
+* More system integration documentation?
projects / oweals / dinit.git / blobdiff