You don't have to reboot the system if init dies

March 16, 2014

One of the thing that makes PID 1 special on many systems is that if it ever exits or dies for any reason, the system will reboot. This behavior was introduced by BSD Unix (V7 ignored the possibility) and makes a certain amount of sense; init is crucial both for reaping orphan processes and restarting serial port logins. If it goes away, rebooting the system is an easy way to hopefully fix the situation.

However, this behavior is not set in stone. There are several alternatives. The first would be to simply have the kernel cope with no PID 1, handling and reaping orphan processes itself internally in some way (and possibly providing some special way for user level to restart a new PID 1). The second is for the kernel to re-exec init as PID 1 if necessary. If PID 1 exits, the kernel would not tear down its process but instead act as if it had done an exec. Ideally this would be accompanied by some way for init to store and then reload important state. Done right this actually provides a great way for init to transition itself into a new version; just record the current state, exit, and let the kernel re-exec the new init binary.

Perhaps the second behavior sounds odd and crazy. Then I should probably tell you that this is current Solaris behavior and nothing seems to have exploded as a result. In other words we already have an existence proof that it's possible to change the semantics of PID 1 exiting, so we could adopt it elsewhere if desired.

Apart from the innate conservatism of Unixes, I think one reason that other Unixes haven't done this is that it's almost never necessary anyways. Since init not exiting is so crucial today people have devoted a lot of engineering effort to make sure that it doesn't happen and have been quite successful at it. Even radically different and complex systems like Upstart and systemd have been extremely stable this way in practice.

(Also, this 're-exec init on failure' behavior needs cooperation from your init, both so that init doesn't always start trying to boot the system when it's executed and so that it journals state periodically so that a new init can pick it up again. This makes it easier to add in certain sorts of Unixes, ie the ones where one team can control both kernel changes and init changes.)


Comments on this page:

By James (trs80) at 2014-03-17 11:15:24:

ISTR (but can't find any references) that back in the day when running your firewall off read-only media to prevent exploitation was a thing, one neat trick was to turn off the panic-on-init config option, set up your firewall with iptables, then have all userspace exit, leaving only the kernel routing and firewalling packets with no attack surface at all.

Written on 16 March 2014.
« Guessing whether people will unsubscribe from your mailing lists
Rebooting the system if init dies is a hack »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 16 00:47:56 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.