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,
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
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.
-* 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