I’ve been investigating alternative system inits from time to time the last few years. With the advent of bootchart, there was quite a hype around improving boot times with parallelization and such. Recently this topic has manifested itself in the initscripts-ng group on alioth, and some to-be Google Summer of Code projects.

I’ve been using a modified version of minit for a long time, just lately I was to lazy and switched back to regular init. Since I use suspend2, I don’t really reboot my system often anyway.

However, minit has more features than being parallel and small. It offers service monitoring and respawning. Which brings me to something missing totally from current linux init systems: service state tracking.

Right now, when you start a service, e.g. the web server, you pretty much hope it will never die. Agreed, apache does a good job here. Others may or may not. Mysql uses a really hackish shell script to respawn. And then there are of course tools like monit that check your services and respawn them when needed.

There are a couple of things wrong with starting services via SysVInit style scripts from the shell. For example, in order to start a service you need root rights. And then this will “leak” file descriptors from your shell to the daemon (thats why some apps need to be started with “nohup”). Which also causes extra errors with SELinux, for example. And this is just one of the differences from services being started by manually running their init script from the script being run by runlevel changes.

Therefore, I think we should move to a new init that can offer full state tracking for services, and is actually used for all services (and not just initial start and getty respawning…)

Here’s a fairly extensive state diagram I came up with:
state model for sysvinit

Some features I’d like to have in a new init:

  • state tracking with interim states
  • dependency management with virtual services (e.g. webserver)
  • service monitoring and respawning
  • control fifos for starting/stopping services through init
  • init monitoring socket for e.g. DBUS connector and service failure notifications

Sorry, no comments on my blog, intentionally. Please use the initscripts-ng mailing list for discussion, thats what the list is for!