doc/COMPARISON

   1 Comparison of Dinit with other supervision / init systems
   2 =========================================================
   3
   4 This is intended to be an objective description of the differences between
   5 Dinit and several other similar software packages. Due to a myriad of details,
   6 it is difficult to provide a very meaningful comparison without going into
   7 great detail (which this document does not). It does, however, serve as a
   8 short survey of service supervision and init systems, and provides a starting
   9 point for understanding the unique features of Dinit.
  10
  11
  12 Systems without dependency management
  13 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  14
  15 A variety of init/supervision packages do not perform proper dependency management
  16 of supervisions. By this I mean that, broadly speaking:
  17  - starting a service should automatically start any services that the former
  18    requires (and wait, if appropriate, until they have started)
  19  - likewise, stopping a service should automatically stop any dependent services.
  20
  21 Dinit (and various other packages) perform dependency management. The following
  22 packages do not:
  23
  24  * Daemontools (http://cr.yp.to/daemontools.html)
  25  * Epoch (http://universe2.us/epoch.html)
  26  * Finit (http://github.com/troglobit/finit)
  27  * Minit (http://www.fefe.de/minit)
  28  * Perp (http://b0llix.net/perp/)
  29  * Runit (http://smarden.org/runit/)
  30
  31 I've read arguments that suggest dependency management isn't really needed: if a
  32 service really does require another, then it fail in some way when the dependency
  33 goes down, and should then go down itself; supervision of the service may try to
  34 restart it, but should use an increasing delay to avoid continuously bouncing the
  35 service up and down. In my opinion this could create unnecessary load, unnecessary
  36 delay, and noise in logs that might make it more difficult to pinpoint the cause
  37 of problems, though I'll acknowledge that in simpler setups these are unlikely to
  38 be real problems.
  39
  40 Not all services will necessarily behave as is required for this type of service
  41 management to work properly. An argument could be made that this is a fault of the
  42 particular service / daemon, but practical considerations may be in play.
  43
  44 The basic problem of starting login sessions only after system initialisation has
  45 (at least partially) completed is naturally solved with a dependency-managing
  46 solution; you can have the tty sessions (getty) depend on some other service unit
  47 which, in turn, depends on the basic system initialisation services. In non-
  48 dependency-handling managers this must usually be special-cased (eg an "inittab"
  49 which is processed once all services have started).
  50
  51 With all the above in mind, I feel that dependency management allows generally
  52 greater flexibility and control in how services are managed. While this might not
  53 always be useful, and comes at a certain cost of complexity, I argue that it is at
  54 least sometimes useful, and that the cost is not so high. However, to be fair,
  55 many systems have successfully taken the simpler approach.
  56
  57
  58 Nosh suite (http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html)
  59 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  60 Another seemingly modular init system offering dependency management and socket
  61 activation, with BSD licensing. Service configuration is expressed through
  62 directory structure (symbolic links represent service dependencies, etc;
  63 "start", "stop" and "run" commands are individual scripts within a service
  64 directory bundle). It provides a simple shell-like scripting language which can be
  65 used (via the "nosh" interpreter) to implement service commands without requiring
  66 the user of a full shell. Several "chain loading" utilities are provided to
  67 allow running processes in a different directory, with a different user id, with
  68 resource limits, etc.
  69
  70 It was originally designed for BSD systems but works on Linux too (i.e. is
  71 portable). It does not provide a D-Bus interface.
  72
  73 Compared to Dinit, the two most significant differences appear to be use of a
  74 directory structure for service configuration (Dinit uses a combination of
  75 directory structure and ini-style configuration file), and use of small chain
  76 loading utilities to implement service parameters (Dinit has a wider range of
  77 direct configuration options via the service description file).
  78
  79 Nosh seems to be a quite mature system with a range of features that makes it
  80 appear competitive, feature-wise, in terms of system/servive management, with
  81 Systemd - though without a lot of the feature-creep extras that can easily be
  82 implemented separately.
  83
  84
  85 OpenRC (Gentoo)
  86 -=-=-=-=-=-=-=-
  87 The OpenRC system used in Gentoo Linux is a dependency-managing service supervision
  88 system with functionality that may similar in some respects to Dinit. According to
  89 Wikipedia, it provides parallel startup of services (like Dinit), though this is
  90 disabled by default. It is designed to be used in conjunction with a primary init
  91 which handles system management and which defers to openrc at boot or shutdown to
  92 bring services up or down.
  93
  94 Unusually, OpenRC does not run as a daemon itself; it terminates once it has
  95 established service states. It has some support for integration with service
  96 supervisors such as S6.
  97
  98 Service configuration is specified via a shell script, with the 'openrc-run'
  99 interpreter (which makes certain special shell functions available, and interprets
 100 shell variables once the service script completes. For performance reasons
 101 metatdata extracted from the service scripts is cached in an alternative format.
 102
 103 Although the build system seems to have some support for BSD OSes, it did not
 104 build successfully on OpenBSD when tested (revision 33d3f33).
 105
 106
 107 S6-RC (http://skarnet.org/software/s6-rc/s6-rc.html)
 108 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 109 S6-RC provides a dependency-management system over the top of the S6 supervision
 110 system. S6-RC requires compiling the complete set of service descriptions into a
 111 database. Services are are configured via a directory structure, with a
 112 one-parameter-per-file style, rather than a single service description file.
 113
 114 As well as services, S6-RC has the concept of service "bundles", named groups
 115 of services that can be started/stopped as a group.
 116
 117 New services cannot be added once the system is in operation, and service
 118 definitions cannot be changed in general, except by re-compiling the database;
 119 S6-RC will then start any new services as required (and stop any processes no longer
 120 considered part of an active service).
 121
 122 S6-RC in general seems to follow the philosophy of breaking up functionality into smaller
 123 parts and implementing these smaller parts as separate programs, wherever
 124 practical. Thus, process supervision, log file management, and service management
 125 are all separate programs.
 126
 127 In contrast to S6-RC, Dinit does not requires compiling service definitions, instead
 128 loading and parsing them on-the-fly. Also, Dinit incorporates service
 129 supervision and management into a single process (and does not require one
 130 supervisory process per service). On the other hand, the Dinit process is
 131 somewhat more complex than any of the individual S6-RC components.
 132
 133 S6-RC nicely manages chaining of service standard input/output, facilitating
 134 setting up a logging chain where a logging process consumes the output of a
 135 service, and either can be restarted while losing only minimal (if any)
 136 output from the logs.
 137
 138 It appears that S6-RC supports only hard dependencies: that is if, a service depends
 139 on another then that service must start, and stay running. Dinit supports a number
 140 of dependency types including "soft" dependencies which allow the dependency to
 141 stop or fail without necessarily stopping the dependent.
 142
 143
 144 Systemd
 145 -=-=-=-
 146 Systemd is probably the most widely used init system on Linux as in recent years.
 147 Compared to Dinit, Systemd provides a range of functionality such as:
 148    - setting priority and various other attributes of the service process that
 149      Dinit does not support [yet].
 150    - seat/session management
 151    - syslogd replacement (or at least, partial replacement)
 152    - ability to run tasks at certain times
 153    - inetd replacement (lazily launch services to handle connection to IP ports)
 154    - asynchronous filesystem check/mount
 155    - control group (cgroup) / container management
 156    - private tmp directories for services / login sessions
 157    - system time management
 158 Some of this functionality can be found in other daemons/packages which can be be used
 159 to supplement the functionality of Dinit or another service manager, and even in the
 160 case of Systemd, some of the functionality is not part of the core process (the
 161 actualy systemd binary).
 162
 163 In Systemd terminology, it manages "units" of which services are one type. In practice
 164 this is an issue only of nomenclature; Dinit "services" and Systemd "units" are, I think,
 165 essentially the same thing.
 166
 167 Systemd running in "system" mode does not properly support running with a PID other than
 168 one [1]. That is, it must replace /sbin/init. Systemd can however be run in "user" mode
 169 where it (most likely) provides roughly the same level of functionality as Dinit, though
 170 in a more complex package.
 171
 172 The Systemd interdependence graph is more complex than for Dinit and most other
 173 dependency-handling service managers: a service can conflict with another service, meaning
 174 that starting one causes the other to stop and vice versa. Systemd implements shutdown
 175 via a special "shutdown" unit which conflicts with other services so that they stop
 176 when the shutdown is "started". Other service managers typically do not implement shutdown
 177 as a service but as a special action; they then don't need to support conflicting
 178 services.
 179
 180 The "shutdown" unit is just one example of a "special" service. Systemd has several such
 181 services, for various purposes, including for tight integration with D-Bus (Systemd
 182 exposes a D-Bus API, and contains its own implementation of the D-Bus protocol).
 183
 184 Systemd makes no attempt to be portable to operating system kernels other than Linux.
 185 The maintainers have stated that they consider it infeasible to port to non-Linux-based
 186 OSes and will refuse patches designed to do so [2]. Dinit, by comparison, strives to be
 187 portable.
 188
 189 [1] http://freedesktop.org/software/systemd/man/systemd.html as at 18/11/2015
 190 [2] http://freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
 191     as at 18/11/2015
 192
 193
 194 Cinit (http://www.nico.schottelius.org/software/cinit; defunct)
 195 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 196 An obscure init system which apparently offers portability and dependency
 197 management, just as Dinit does. Development appears to have ceased some
 198 time ago, unfortunately.
 199
 200
 201 InitNG (http://initng.org/trac; defunct)
 202 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 203 A highly modular init system which apparently offers dependency management
 204 (as Dinit does). Portability status is unclear; may be Linux-only (Dinit
 205 strives for portability). Development may have ceased (website is now showing
 206 Japanese text which I am unable to read) although there are what looks like
 207 maintenance commits from 2017 in the Github repository at
 208 https://github.com/initng/initng.
 209
 210
 211 Upstart (Ubuntu; http://upstart.ubuntu.com)
 212 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 213 Upstart does not provide real dependency management; instead "events" (including services
 214 starting or stopping) can be specified to trigger start/stop of other services. This is
 215 backwards from the Dinit approach (and that taken by most dependency-managing supervision
 216 systems) which allow the dependencies of a service to be specified declaratively. That is,
 217 if service A depends on service B, Upstart is configured so as to start B whenever A starts
 218 (and it's not possible, or at least not trival, to start A without also starting B).
 219
 220 Upstart apparently offers a D-Bus interface. Dinit eschews D-Bus in favour of a simple
 221 custom control protocol.