linux/UpstartCouplingProblemII written at 00:38:01; Add Comment
Fixing Upstart's coupling of startup script presence and activation
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
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 '
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
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.)
* * *
Atom feeds are available; see the bottom of most pages.