1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495 |
- For version 0.9.1
- -----------------
- * update docs re pinning
- * control protocol: START: add response case for not starting because pinned in stopped
- * make sure process/bgprocess correctly handle stop when the process has already died
- (i.e. when pinned-started but process died)
- * [DONE] pinned-stopped service should prevent dependent from starting (like failure)
- For version 0.10.0:
- -------------------
- * Check that desired_state is getting set correctly. (Currently we don't decide whether a service
- will restart until it stops...)
- * for non-system init, fail to start if the control socket exists
- * fail to start if control socket already exists (unless running as system mgr)
- For version 0.11.+:
- ------------------
- * 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).
- * Documentation must be complete (see section below).
- * Proper support for socket activation?
- * Chaining of service process input/output?
- * Be able to boot and shutdown Linux and FreeBSD (or OpenBSD).
- 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)
- * Perhaps need a way to prevent script services from re-starting.
- (eg there's no need to mount filesystems twice; there might be various other
- system initialisations that can't or shouldn't really be "undone" and so do
- not need to be re-done).
- * Internationalisation
- * A service can prevent shutdown/reboot by failing to stop. Maybe make
- multiple CTRL-ALT-DEL presses (or ^C since that's more portable) commence
- immediate shutdown (or launch a simple control interface).
- * When we take down a service or tty session, it would be ideal if we could kill
- the whole process tree, not just the leader process (need cgroups or pid
- namespace or other mechanism).
- * Allow logging tasks to memory (growing or circular buffer) and later
- switching to disk logging (allows for filesystem mounted readonly on boot).
- 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:
- -------------------------
- * Support recognising /etc/init.d services automatically (as script services, with
- no dependency management - or upstart compatible dependency management)
- Also BSD's rc.d style scripts (PROVIDE, REQUIRE).
- * Place some reasonable, soft limit on the number of services to be started
- simultaneously, to prevent thrashing. Services that are taking a long time
- to start don't count to the limit. Maybe use CPU/IO usage as a controlling
- factor.
- * Cron-like tasks (if started, they run a sub-task periodically. Stopping the
- task will wait until the sub-task is complete).
- * Allow to run services attached to virtual tty, allow connection to that tty (ala "screen").
- * SystemD-like handling of filesystem mounts (see autofs documentation in kernel)
- i.e. a mount point gets an autofs attached, and lazily gets mounted when accessed
- (or is mounted in parallel). Probably put the functionality in a separate daemon.
- Documentation:
- --------------
- * Design philosophy/rationale document
- * More system integration documentation?
|