Update README and TODO
authorDavin McCall <davmac@davmac.org>
Sun, 19 Jun 2016 13:32:57 +0000 (14:32 +0100)
committerDavin McCall <davmac@davmac.org>
Sun, 19 Jun 2016 13:32:57 +0000 (14:32 +0100)
README
TODO

diff --git a/README b/README
index 77d7f140bad1ba33b3df5b0d15c36af661d43fc6..a5a98f981bb05e069cf67b4e5df87f342832f46b 100644 (file)
--- 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 60240759396c36ac21bf35feef5be7a71684a842..62e976fe7090a187d70d55073a2e413e55162e19 100644 (file)
--- 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