Chris's Wiki :: blog/linux/PackagingStartupScripts

Dear software packagers, startup scripts edition

May 4, 2010

This is a grump.

Dear packagers of software for Linux distributions, please note this: just because I have your software installed does not mean that I want to run your daemon. Database systems, I am especially looking at you. Please package software accordingly, and please make sure that daemons stay turned off and not running even when harried sysadmins apply package upgrades.

Since the natural way for a harried sysadmin to make a daemon not run is to turn off its init.d script (with chkconfig on Red Hat derived systems and update-rc.d on Debian derived ones), your packaging should ideally support this. This means that you should not automatically recreate the /etc/rcN.d symlinks on updates; instead you should leave things alone, with whatever symlinks in place (or not in place) that are already there.

(Red Hat derived systems seem to be good about this. Debian derived ones, not so much. But perhaps I misunderstand the zen of Debian systems and the natural way to turn daemons off is not with update-rc.d, although I will point out that there are reasons to juggle the boot time priorities too.)

If you have another way to disable your daemon, especially if manipulating /etc/rcN.d symlinks is not reliable, you should absolutely mention it in a comment at the start of your init.d script. Really. If it is not there, or at least in a very prominent place in your distribution specific README, it might as well not exist until some sysadmin gets very, very aggravated with you some day.

In case you are curious, we have database systems installed but don't run their daemons because we want to let users run them if they need MySQL or PostgreSQL but we have absolutely zero interest in running a system database instance due to the hassles of backing it up, creating and managing database users and databases, dealing with space issues, and so on. If one of our users wants PostgreSQL or MySQL, they can deal with all of that themselves (and the space that their database uses comes out of their home directory or some other filesystem that they have access to).

Sidebar: how to disable the PostgreSQL daemon on Ubuntu (8.04)

Change /etc/postgresql/<VER>/main/start.conf to another option besides auto. The comments in the script will tell you what your other options are.

On a casual inspection, I can't see any way to do this for MySQL. Get used to running 'update-rc.d -f mysql remove' after every MySQL update. Oh, and you need to stop the daemon too, since the Ubuntu postinst package appears to default to auto-starting the daemon after an upgrade.

(I would love to be wrong about this.)

Comments on this page:

From 124.169.223.43 at 2010-05-04 01:49:31:

On Debian it's a recongised problem.

James

From 78.142.172.145 at 2010-05-04 04:34:14:

Well, on Debian (can't really speak for Ubuntu), you - as a sysadmin - are not supposed to call update-rc.d (this is also stated in it's manpage, and it shows in that you have to pass -f to remove).

Rather, manually delete the /etc/rcN.d/S*mysql links. This /should/ make sure, that update-rc.d (when called from the mysql-server postinst) does NOT re-create the "missing" startup links.

Otherwise, I'm completely with you for daemons should not be auto-installed and not auto-started.

From 78.142.172.145 at 2010-05-04 04:35:43:

It might also be beneficial to add a site-wide /usr/sbin/policy-rc.d which prevents start of daemons using invoke-rc.d (which every postinst is supposed to use). Don't know if this helps in the postgres/mysql cases, if not, I'd file a bug against them.

From 82.69.23.129 at 2010-05-04 04:42:39:

Very annoying that so many Debian packages start daemons automatically on installation. For managing init scripts I have been happily using sysv-rc-conf - it has a very well designed console interface for enabling / disabling init scripts.

David B

By cks at 2010-05-04 12:15:43:

Well, on Debian (can't really speak for Ubuntu), you - as a sysadmin - are not supposed to call update-rc.d (this is also stated in it's manpage, and it shows in that you have to pass -f to remove).

Rather, manually delete the /etc/rcN.d/S*mysql links. [...]

This is crazy, because all update-rc.d does on remove is remove the symlinks. So it's right for me to remove them by hand (not that it works, of course), but wrong for me to use a system-supplied program that removes the symlinks?

[...] This /should/ make sure, that update-rc.d (when called from the mysql-server postinst) does NOT re-create the "missing" startup links.

This is not at all how update-rc.d works (at least in Ubuntu 8.04); you can try it out (or read the Perl script and the postint scripts yourself). update-rc.d is unconditionally invoked in postinst scripts and unconditionally creates /etc/rcN.d symlinks, regardless of whether this is a fresh package being installed for the first time or an upgrade.

From 78.142.172.145 at 2010-05-05 04:16:34:

This is crazy, because all update-rc.d does on remove is remove the symlinks. So it's right for me to remove them by hand (not that it works, of course), but wrong for me to use a system-supplied program that removes the symlinks?

I don't know what update-rc.d does on Ubuntu, but this is what happens on Debian lenny:
 ch@percival:~ % ls /etc/rc*.d/*mysql-ndb
 /etc/rc0.d/K21mysql-ndb@  /etc/rc1.d/K21mysql-ndb@  /etc/rc6.d/K21mysql-ndb@
 ch@percival:~ % sudo update-rc.d mysql-ndb defaults 18 22
 System startup links for /etc/init.d/mysql-ndb already exist.
If you check the postinst, you'll see that it does the same.

The magic here is: update-rc.d remove removes all rcN.d symlinks. This is indistinguishable from a fresh install. If you, manually, remove the SNN symlinks (and keep the KNN symlinks), update-rc.d will notice that this is NOT a fresh install, and will NOT re-create the startup links.

So yes, it's right for you to remove the symlinks (but not all of them), but wrong to use a system-supplied program (which manpage states that you are not to use it) which does somewhat the same (but not what you want).

You might find sysv-rc-conf useful, as it seems to produce output similar to chkconfig:
 ch@percival:~ % sudo sysv-rc-conf --list mysql-ndb
 mysql-ndb    0:off      1:off   6:off
 ch@percival:~ % sudo sysv-rc-conf  mysql-ndb off
 ch@percival:~ % sudo sysv-rc-conf --list mysql-ndb
 mysql-ndb    0:off      1:off   2:off   3:off   4:off   5:off   6:off

By cks at 2010-05-05 04:40:29:

Oh whoops, my error; I missed that you specified just removing the S* symlinks, not the K* symlinks. Indeed, Ubuntu 8.04's update-rc.d doesn't recreate the S* links if there are K* links, so you're entirely right and I'm wrong.

Well. Colour this situation crazy, especially as sysv-rc-conf doesn't appear to be a default package on Ubuntu and update-rc.d breezily tells people to do the common operation by hand instead of, say, having an option that does the right thing.

(It would not be a difficult option; 'update-rc.d <what> disable', it would remove any S* links and create or leave K* links.)

Note that I do not consider leaving the K* links lying around to be a good thing in general. I do not have a high confidence that random init scripts will do the right thing if there is an instance of 'their' daemon in the process list but they didn't actually start it; I have seen too many that blithely made a great deal of assumptions in this area.

From 78.142.172.145 at 2010-05-05 06:16:26:

Yep, the entire situation could be better.

Now that I think about the K links a bit more, the "best" thing to do is probably this: /Remove all symlinks, except the K links in rc0.d, rc6.d./

This way, you somehow ensure that the daemon - if manually started with the init script - gets shut down on shutdown/reboot. If the init script misbehaves, and shuts down a daemon it does not own, bummer. It'd be killed anyway a few minutes later by killall.

And no, this can't be done with sysv-rc-conf.

Does this leave any problems during normal operations? (Except that update-rc.d could be more helpful.)

Written on 04 May 2010.

«	Keeping track of filesystem consistency

The right way to fix ZFS disk glitches (at least for us)