Why I am unhappy with Upstart right now
Upstart has a little problem: it erases the difference between something
having a startup script and whether that script is activated or
not. There is no equivalent in Upstart to the distinction between
/etc/init.d and /etc/rc?.d; everyone puts startup configurations
directly in /etc/init, where Upstart will process them. This matters
quite a lot to me, because there are plenty
of packages that we want installed without having their daemons be
active.
Editing the /etc/init file is not a solution (even if it's done by a
script), because the file is owned by the package, not the sysadmin. An
Upstart .conf file contains a great deal more than whether or not a
daemon is enabled (and under what circumstances); it also has how to
start the daemon and what associated processing you need to do. This
means that its contents are logically tied to the rest of the package
and may need to be updated when the rest of the package is.
If you edit the file and the package is updated, either your changes are lost (and the daemon either starts running when you didn't want it to or stops running when you did) or you now get to merge your changes with the package's changes by hand. Neither is a good outcome when all you wanted to do was stop the MySQL daemon from running by default.
There's also a consequence for how people package daemons. It used to
be that a lot of daemons were shipped in a default-disabled state,
where after installation they were just available but you had to use
chkconfig or the equivalent to turn them on. This was perfectly viable
when we had a chkconfig (and GUI versions of it), but Upstart removes
all that and makes it much more difficult and annoying to change the
enabled/disabled state of a daemon. I suspect that the result will be a
lot more daemons being installed default-enabled (if the packager has to
pick an option, it's the more useful one), and in turn this means I'll
be installing a lot less daemons.
Comments on this page:
|
|