TODO

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