Fixing Upstart's coupling of startup script presence and activation

October 10, 2010

While Upstart has the problem of joining together the idea of a startup script being present and it being active (per my earlier entry), there is a relatively simple way of distributions to fix this while preserving all of the benefits of Upstart.

Although Upstart sort of apes traditional runlevels, it really operates based on events; services declare what events they depend on, and they start when those events happen. Upstart events are completely abstract (although it has some built in ones), and they can be generated by hand; 'initctl emit fooevent' will tell Upstart that fooevent has happened.

Given that Upstart startup scripts can be configured to only start when multiple events have happened, the fix is straightforward; you make all services depend not only on their usual events but also on a synthetic <service>-enabled event. The system generates all of the necessary *-enabled events during boot, based on some scheme to keep track of which services are enabled (and possibly which runlevels they're enabled in, although runlevels don't really make much sense any more).

(How exactly the system keeps track of what enabled events to emit is a small matter of design. I suspect that the best one is a directory somewhere, because creating and deleting files in a directory has proven to work well for other similar problems. A script to emit suitable events is then basically 'cd /etc/somewhere && for i in *; do initctl emit $i-enabled; done'.)

As a side effect this preserves all of the virtues of the current Upstart setup, such as being able to start services by hand with initctl (something that is not preserved by schemes that require symlinks or renaming files). It also needs no grand re-architecting of Upstart or the rest of the system, and could be rolled out easily and incrementally by any distribution that wants to (especially since distributions are already customizing Upstart service config files or writing them from scratch).

Sadly I suspect that the odds of Ubuntu or any other Upstart-using distribution adopting such a thing are relatively low. (Perhaps Fedora will give me a pleasant surprise.)


Comments on this page:

From 124.169.241.77 at 2010-10-11 09:42:24:

Fedora is switching to SystemD anyway, isn't it?

James

Written on 10 October 2010.
« An illustration of how careful and clever spammers are today
The Unix directory problem and the history of directories »

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

Last modified: Sun Oct 10 00:38:01 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.