From b028e1e479078389480e702d6c33dd530ce0b141 Mon Sep 17 00:00:00 2001 From: Davin McCall Date: Sun, 19 Jun 2016 14:32:57 +0100 Subject: [PATCH] Update README and TODO --- README | 24 +++++++++++++++++++----- TODO | 28 ++++++++-------------------- 2 files changed, 27 insertions(+), 25 deletions(-) diff --git a/README b/README index 77d7f14..a5a98f9 100644 --- a/README +++ b/README @@ -14,10 +14,14 @@ but see notes below) in parallel, with dependency management (i.e. if one service's operation depends on another, the latter service will be started first). -For "process" services dinit can monitor the process corresponding to the +For "process" services Dinit can monitor the process corresponding to the service, and re-start it if it dies. It does this in an intelligent way, -first "rolling back" all dependent services (which it will later re-start, -if configured to do so). +first "rolling back" all dependent services, and restarting them when their +dependencies are satisfied. + +Dinit includes a tool ("dinitctl") to issue commands to the main Dinit +process, and a "shutdown" program (with scripts "halt" and "reboot") to +manage shutting down and restarting the system. Dinit is designed to work on POSIXy operating systems such as Linux and OpenBSD. It is written in C++ and uses the "Dasynq" event handling library, @@ -71,8 +75,13 @@ process that is registered as a scripted service). A _bgprocess_ service is a mix between a process service and a scripted service. A command is used to start the service, and once started, the process ID is expected to be available in a file which Dinit can then -read. Many existing daemons can operate in this way. Dinit can only -supervise the process if it runs as the system "init" (PID 1), +read. Many existing daemons can operate in this way. Dinit can only supervise +the process if it runs as the system "init" (PID 1) - otherwise Dinit will +not know when the process has terminated. + +(Note, use of bgprocess services type requires care. The file from which the +PID is read is trusted; Dinit may send signals to the specified PID. It +should not be possible for unauthorised users to modify the file contents!) An _internal_ service is just a placeholder service that can be used to describe a set of dependencies. An internal service has no corresponding @@ -223,3 +232,8 @@ runs-on-console = yes | no | true | false Process services and internal services take the console for the entire time that they are active (and cannot release it). +options = ( runs-on-console | nosigterm | starts-rwfs | starts-log ) ... + This is a newer way of specifying some of the above options + (runs-on-console, nosigterm, onstart = rw_ready) and an additional option + for specifying that this service is the system logging service, which + Dinit can log to once the service has started. diff --git a/TODO b/TODO index 6024075..62e976f 100644 --- a/TODO +++ b/TODO @@ -1,38 +1,26 @@ -* BGPROCESS services: - - document security issue if pid file is not correctly protected (via access - rights/ownership). - -* libev replacement: - - We've replaced libev, so that we don't abort on failure. But now exceptions - can be thrown when we register an event watch - need to handle these. - - Service I/O / child process waits need to be audited. - -* Long-running "on console" services will back up the circular log buffer. - The buffer should just be flushed instead. -* When a PROCESS service process dies, and smooth_recovery is false, probably - need to force-stop dependents even if the process itself was stopped - deliberately. * Complete control socket handling and protocol - support for listing all services and their state * Implement a control utility to start/stop services after dinit has started - very basic version exists, needs thorough cleanup +* Redundant settings ("onstart" commands etc) should be removed + (see description of "options" setting). For version 1.0: ---------------- -* 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). * Documentation including sample service definitions * Better error handling, logging of errors (largely done, still some patches of code where it may be missing). * Write wtmp entry on startup (see simpleinit) * Allow running services as a different UID + +For later: * 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) - -For later: +* 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 * More logging options. Can currently log to syslog only (well, with the syslog protocol, to /dev/log). Possibly should be able to log directly -- 2.25.1