tobold.org

correct • elegant • free

Starting svscan in recent Linux distributions

Good news: the unspeakable SysV init dreck, which somehow wormed its way into the popular Linux distributions, is moribund. It has been replaced by upstart in Fedora (since at least F9, possibly earlier). The upstart project appears to have come from Ubuntu, so I guess that similar remarks apply there, too.

Bad news: upstart still has /etc/inittab, but it only uses it to discover the default runlevel. All other lines are silently ignored. Since daemontools assumes that, if a system has /etc/inittab, it uses /etc/inittab, a daemontools install on recent Linux boxes fails to result in a running svscan.

This is what I'm currently using to start svscan:

# cat /etc/event.d/svscan
start on startup
respawn
exec /command/svscanboot

This line start on startup starts svscan very early; so early, in fact, that the root file system is still mounted read-only, creating a bit of noise in readproctitle. I haven't yet found a better way to handle this. I feel that it should be possible to say something like start on rc1 stopped so that this job is started just as the system starts to go multiuser. That won't work; rc1 is only run as we drop into singleuser mode. Maybe start on started rc[2345] would do the trick, but I'd prefer to pretend that SysV runlevels don't exist! BSD done it better (eventually: I'm thinking of rcorder which wasn't in 4.4BSD).

Also, I suspect that respawn should be replaced by the two lines daemon and service. As it stands, init restarts svscan just after it's been killed during system shutdown!

To start svscan the first time, without rebooting, run the command initctl start svscan.