Today’s post (previous parts) tries to show what benefits other init systems can offer.

I’m picking ‘minit’ as an example; not because it’s the ultimate solution or anything, but because I happen to know it quite well. I used to be the package maintainer for some time, and I’ve also used it on an embedded system (where it was a perfect match). However, it’s not very distribution-friendly; it’s great when you can invest some time into configuring it (such as when building an embedded system) but not when it should ideally work automatically out of the box. The Debian package is still there, but it’s orphaned. Still it’s well written, clean code; there shouldn’t be any bigger bugs in there.

The first thing to notice is that minit is tiny. It’s statically linked, but only about 6.5 kb. Regular init is 86 kb plus some libraries (despite actually not doing much during init!). This makes it very well-suited for embedding.

But now for the benefits of minit over regular init:

  1. Service monitoring. This is the biggest point: minit will keep an eye on the services and restart them when needed. (Another thing very useful in embedded situations, btw.)

Minit doesn’t use the start/stop paradigm of sysv/shell-style-init. Instead it has a “run” script for every service. If a service is flagged as ‘respawn’, it will automatically be restarted when the run script quits; therefore the applications should not background themselves. This offers some benefits, for example the init process will be notified by the kernel of a termination, and can immediately respawn the service; in contrast to other monitoring systems suchas monit it doesn’t rely on ‘busy polling’.

  1. Dependency handling. Minit handles startup dependencies. If a service lists another service as a dependency, it will bring that service up first.

  2. Parallel startup. Unless an ordering is given via dependencies, minit will start the services in parallel.

  3. Control apps. In minit, you don’t start a service by running some random shell script. Instead you call “msvc -u servicename”, which will signal minit to bring up the service (and it’s dependencies). This would (there currently is no policy for minit) be especially useful in SELinux, but it also allows to e.g. give a user the permission of running “sudo msvc -u” without introducing a huge security hole, since this cannot be used to execute arbitrary scripts. “msvc” can also be used to check if a service is up. (Another benefit for embedded systems, since that removes the need for pid files, which then need a ram (writeable) filesystem)

I’ll also give an example for a minit service:

A service is represented by a directory in /etc/minit which can contain various files. I’m going to look at getty/1 example; which will bring up a console login on the first terminal. There are three files:

  • a symlink named ‘run’ to /sbin/getty, which is the daemon we want to bring up
  • a file named ‘params’ containing the parameters for the getty application, one per line
  • an empty file named ‘respawn’, since we want the login screen to reappear

If the service would need it, there could also be a file called “depends” listing service dependencies.

This allows minit to start the getty with no overhead. There is no shell script being executed or anything (note: sysvinit also does this for gettys, but it’s not being used much for other services).

Of course minit isn’t perfect. I’ve already said that it isn’t particularly distribution friendly. This is because it uses a lot of magic files (e.g. an empty file named ‘respawn’ to flag a service as needing to be respawned), and it’s configuration files aren’t easy to handle automatically. The often frowned-upon ‘symlink farms’ of sysv-shell-style init are much better here.

Another thing that is missing from minit is an automatic rollback of dependencies. If we told minit to bring up service ‘a’, which lists dependencies ‘b’ and ‘c’, minit will bring these three up. If we tell it to shutdown ‘a’, it will however not shutdown ‘b’ or ‘c’. And unfortunately, even if we shutdown ‘b’, it won’t shutdown ‘a’. If you want a more complex dependency handling (or things such as runlevels), you need to do this externally. (An example is my ‘enitdir’ app, it adds runlevel support to minit, and allows switching of runlevels by replacing a symlink; Services are added and removed from runlevels by adding a symlink to the service into the runlevels directory. By using dnotify, this also takes virtually no CPU time.)

Minit also lacks a differentiation between a ‘started’ and a ‘running’ service. It has support for ‘sync’ services, such as e.g. mounting a filesystem. It will wait for this operation to complete before it starts services depending on it. However, there are services that will continue to run, while not being instantly available when the exec() was called. Sometimes it would be nice if a service could go into a ‘started’ state, then do some cleanup work, and then when actually running the real service signal minit that it’s now ‘running’.

As a last malus, minit won’t print progress messages to the console. A minit boot is pretty much silent, directing it’s output to some logging processes. There are good reasons for this (since services are started in parallel!), but it makes debugging harder, and users might be wondering what their system is actually doing (though some users prefer to see a colored ‘busy’ bar)…

I guess this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? I hope to have given an impression on where there is room for improvement in our current init to one or the other. Now we just need some people to actually work on a better support for other inits in Debian…