2 * Complete control socket handling and protocol
3 - support for pinned-start and pinned-stop
4 - support for listing all services
5 * Implement a control utility to start/stop services after dinit has started
6 - very basic version exists, needs thorough cleanup
10 * Log messages are completely prevented from going to the console if the console
11 is being held by a service, meaning some can get lost. It would be better if
12 there was a (limited) buffer.
13 * Perhaps need a way to prevent script services from re-starting.
14 (eg there's no need to mount filesystems twice; there might be various other
15 system initialisations that can't or shouldn't really be "undone" and so do
16 not need to be re-done).
17 * Add command line arg to start in "PID 1" mode (even if PID != 1).
18 Basically, allow running as a system service monitor, without
19 requiring that dinit runs as PID 1.
20 * if PID != 1, choose a more sensible service definition directory
21 (something like $HOME/dinit.d)
22 * Documentation including sample service definitions
23 * Better error handling, logging of errors
24 * Write wtmp entry on startup (see simpleinit)
25 * Allow running services as a different UID
28 * A service can prevent shutdown/reboot by failing to stop. Maybe make
29 multiple CTRL-ALT-DEL presses (or ^C since that's more portable) commence
31 * Interruptible scripted services - where it's ok to terminate the start
32 script with a signal (and return the service to the STOPPED state). So a long-
33 running filesystem check, for instance, need not hold up shutdown.
34 * When we take down a service or tty session, it would be ideal if we could kill
35 the whole process tree, not just the leader process.
36 * Investigate using cn_proc netlink connector (cn_proc.h) to receive process
37 termination events even when running with PID != 1 (Linux only).
38 Also, there is the possibility of having a small, simple PID-1 init which
39 sends terminated process IDs over a pipe to Dinit.
40 * Allow logging tasks to memory (growing or circular buffer) and later
41 switching to disk logging (allows for filesystem mounted readonly on boot)
42 * Rate control on process respawn
43 * Allow running services with different resource limits, chroot, cgroups,
44 namespaces (pid/fs/uid), etc
45 * Make default control socket location build-time configurable
46 * Allow specifying a timeout for killing services; if they don't die within
47 the timeout (after a TERM) then hit them with a KILL.
49 Even later / Maybe never:
50 * Support recognising /etc/init.d services automatically (as script services, with
51 no dependency management - or upstart compatible dependency management)
52 Also BSD's rc.d style scripts (PROVIDE, REQUIRE).
53 * Place some reasonable, soft limit on the number of services to be started
54 simultaneously, to prevent thrashing. Services that are taking a long time
55 to start don't count to the limit. Maybe use CPU/IO usage as a controlling
57 * Cron-like tasks (if started, they run a sub-task periodically. Stopping the
58 task will wait until the sub-task is complete).
59 * Socket activation of services? Not sure if enough non-SystemD derived
60 daemons actually support this to warrant implementing it.
61 * Allow to run services attached to virtual tty, allow connection to that tty (ala "screen").
62 * SystemD-like handling of filesystem mounts (see autofs documentation in kernel)
63 i.e. a mount point gets an autofs attached, and lazily gets mounted when accessed
64 (or is mounted in parallel). Probably put the functionality in a separate daemon.
69 * What's the best TERM setting? gogetty gives me "linux" but I think other variants may be
70 better (eg "linux-c").
72 * Figure out the ConsoleKit/logind / PolicyKit mess & how dinit needs to fit into it.
73 * Consolekit/logind tracks "sessions". Provides a mechanism to mark a session starting,
74 associates processes with sessions, provides calls to terminate sessions etc (why?!!)
75 Can use environment variable or cgroups to track processes in a session.
76 A PAM module exists to create/destroy sessions.
77 * Consolekit/logind also allows for requesting shutdown, reboot, and inhibiting reboot
79 * "seats" are a set of input/output hardware (mouse/keyboard/monitor) on which a session
80 can be run. You can have multiple sessions on a seat - one is in the foreground
81 (eg linux virtual ttys implement multiple sessions on a single seat).
82 Sessions can run without a seat (eg ssh session).