The Upstart dependency problem
April 23, 2011
We just ran into another issue with how Upstart handles startup scripts. The simple way to put it is that Upstart glues together the startup script itself and ordering dependency information on when it needs to be run. This is a problem because the startup script is 'owned' by the package but dependencies can be system dependent, which means that local sysadmins need to change them.
(This is similar to the previous Upstart coupling problem.)
Now, the old
With Upstart, the only way to modify or add ordering dependencies is to
modify the actual
You know, I had thought that both the sysadmin world and the Linux
world had learned a lesson about shoving unrelated information into the
same file. In fact the Linux world has spent years carefully splitting
monolithic files into separate, much easier to manage things; this is
what gave us such things as
(It is especially annoying because almost all of the
Sidebar: an example of why ordering dependencies are system-dependent
We have a chain of dependencies for a machine getting its NFS mounts up. For reasons beyond the scope of this entry, mounting any NFS filesystem requires that the SSH daemon be running on the client, then our automounter replacement requires a single NFS filesystem be mounted first. So far, so good; we can do all of this with our own custom init scripts with their own ordering without needing to change system ones.
Then we add our system of user-run webservers. The simple way to start user-run webservers
on boot is for users to have crontabs with
* * *
Atom feeds are available; see the bottom of most pages.