From: Davin McCall Date: Wed, 30 Dec 2015 00:35:32 +0000 (+0000) Subject: Documentation updates. X-Git-Tag: v0.01~83 X-Git-Url: https://git.librecmc.org/?a=commitdiff_plain;h=63d7f15b6f620901963fad1ffa0760510ddbbaa5;p=oweals%2Fdinit.git Documentation updates. --- diff --git a/README b/README index 7f20163..d1b25d6 100644 --- a/README +++ b/README @@ -21,6 +21,8 @@ if configured to do so). Dinit is designed to work on POSIXy operating systems such as Linux and OpenBSD. It is written in C++ and uses the "libev" event handling library. +Development goals include clean design, robustness, portability, and +avoiding feature bloat (whilst still handling a variety of use cases). See doc/COMPARISON for a comparison of Dinit with similar software packages. diff --git a/TODO b/TODO index fc4ee93..cee18f6 100644 --- a/TODO +++ b/TODO @@ -1,5 +1,34 @@ +* License +* Complete control socket handling and protocol + - support for pinned-start and pinned-stop + - support for listing all services +* Implement a control utility to start/stop services after dinit has started + - very basic version exists, needs thorough cleanup +* Service rollback (for shutdown/reboot etc) should unpin pinned-started services. + For version 1.0: ---------------- +* Think about shutdown. TTY services: + - potentially don't respond to SIGTERM (eg interactive bash doesn't, though it + does to SIGHUP) or even any signal other than SIGKILL. + - but SIGKILL is a big hammer to wield immediately. + - termination timeouts could solve this. + - another way: the option to not wait for the process to terminate as a + per-service flag (or to wait for a limited time) + - ideally, we want to signal all processes in the session, not just the session + leader. +* Re-think handling of crashing daemons. If udevd crashes for example it should not + bring the whole system down. On the other hand udevd failing to start *should* + prevent the system from booting further. + - maybe make it possible to mark services as "once it's up it's up", so eg you + can mark loginready and/or tty services as such. These services will not + stop if their dependencies stop. On the other hand this subverts the dependency + system. *** Now have this - "pinned started" state. + - Another possibility is to mark process services so that they will restart the + process without bringing the service itself down. (Maybe this should be the + default for auto-restart services anyway). + - Perhaps also need a way to prevent script services from re-starting. + (eg there's no need to mount filesystems twice). * Add command line arg to start in "PID 1" mode (even if PID != 1). Basically, allow running as a system service monitor, without requiring that dinit runs as PID 1. @@ -7,7 +36,6 @@ For version 1.0: (something like $HOME/dinit.d) * Documentation including sample service definitions * Better error handling, logging of errors -* Implement a control utility to start/stop services after dinit has started * Write wtmp entry on startup (see simpleinit) * Allow running services as a different UID @@ -37,7 +65,8 @@ Even later: daemons actually support this to warrant implementing it. * Allow to run services attached to virtual tty, allow connection to that tty (ala "screen"). * SystemD-like handling of filesystem mounts (see autofs documentation in kernel) - i.e. a filesystem become ready is equivalent to a service starting. + i.e. a mount point gets an autofs attached, and lazily gets mounted when accessed + (or is mounted in parallel). Probably put the functionality in a separate daemon. Documentation: diff --git a/doc/COMPARISON b/doc/COMPARISON index f6a70e9..a65b4ea 100644 --- a/doc/COMPARISON +++ b/doc/COMPARISON @@ -2,7 +2,43 @@ Comparison of Dinit with other supervision / init systems ========================================================= This is intended to be an objective description of the differences between Dinit -and several other similar software packages. +and several other similar software packages. I started writing this with the +intention of justifying Dinit's existence, but don't know feel that this +document achieves that goal. It does, however, serve as a short survey of +service supervision and init systems. + + +Systems without dependency management +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- + +A variety of init/supervision packages do not perform proper dependency management +of supervisions. By this I mean that: + - starting a service should automatically start any services that the former + requires (and wait, if appropriate, until they have started) + - likewise, stopping a service should automatically stop any dependent services. + +Dinit (and various other packages) perform dependency management. The following +packages do not: + + * Daemontools (http://cr.yp.to/daemontools.html) + * Epoch (http://universe2.us/epoch.html) + * Finit (http://github.com/troglobit/finit) + * Minit (http://www.fefe.de/minit) + * Perp (http://b0llix.net/perp/) + * Runit (http://smarden.org/runit/) + + +Cinit (http://www.nico.schottelius.org/software/cinit) +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +An obscure init system which apparently offers portability and dependency +management, just as Dinit does. + + +InitNG (http://initng.org/trac) +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +A highly modular init system which apparently offers dependency management +(as Dinit does). Portability status is unclear; may be Linux-only (Dinit +strives for portability). OpenRC (Gentoo) @@ -17,6 +53,23 @@ startup of services (like Dinit). Compared to Dinit: build successfully on OpenBSD when tested (revision 33d3f33). +S6-RC (http://skarnet.org/software/s6-rc/s6-rc.html) +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +S6-RC provides a dependency-management system over the top of the S6 supervision +system. Apparently it maintains most state on disk. S6-RC requires compiling the +complete set of service descriptions into a database. New services apparently +cannot be added once the system is in operation. + +S6 in general follows a philosophy of breaking up functionality into smaller +parts and implementing these smaller parts as separate programs, wherever +practical. Thus, process supervision, log file management, and service management +are all separate programs. + +In contrast, Dinit does not requires compiling service definitions, and allows +new services to be added after the system starts. Also, Dinit houses a much larger +body of functionality in a single executable program. + + Systemd -=-=-=- Systemd is probably the most widely used init system on Linux as of the last year @@ -35,9 +88,9 @@ or two. Compared to Dinit: be used to supplement the functionality of Dinit. - Systemd running in "system" mode does not properly support running with a PID other than 1 [1]. That is, it must replace /sbin/init. Systemd can however be run in - "user" mode where it (most likely) provides the same level of functionality of - Dinit, though in a more complex package. - - Systemd exposes a D-Bus API. + "user" mode where it (most likely) provides the same or greater level of functionality + as Dinit, though in a more complex package. + - Systemd exposes a D-Bus API. Dinit eschews D-Bus in favor of a compact custom protocol. - Systemd makes no attempt to be portable to operating system kernels other than Linux. The maintainers consider it infeasible to port to non-Linux-based OSes and will refuse patches designed to do so [2]. Dinit, by comparison, strives to be @@ -46,3 +99,16 @@ or two. Compared to Dinit: [1] http://freedesktop.org/software/systemd/man/systemd.html as at 18/11/2015 [2] http://freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ as at 18/11/2015 + + +Upstart (Ubuntu; http://upstart.ubuntu.com) +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Upstart does not provide real dependency management; instead "events" (including services +starting or stopping) can be specified to trigger start/stop of other services. This is +backwards from the Dinit approach (and that taken by most dependency-managing supervision +systems) which allow the dependencies of a service to be specified declaratively. That is, +if service A depends on service B, Upstart is configured so as to start B whenever A starts +(and it's not possible, or at least not trival, to start A without also starting B). + +Upstart apparently offers a D-Bus interface. Dinit eschews D-Bus in favour of a simple +custom control protocol.