Ubuntu
debhelper package

debhelper script creates prerm script that causes daemon removal to be impossible

Bug #119454 reported by bruenig on 2007-06-09

Affects		Status	Importance	Assigned to	Milestone
	debhelper (Ubuntu)	Invalid	Undecided	Unassigned
	tftp-hpa (Ubuntu)	Fix Released	Undecided	Unassigned

Bug Description

For daemons, the debhelper scripts create a prerm script that says something like this:
if [ -x /etc/init.d/daemon ]; then
/etc/init.d/daemon stop

The problem with this is that often times these daemons output nonzero exit codes when you try to stop a daemon that isn't already running. So you apt-get remove daemon and it says it can't do it because the prerm script had an error. This is problematic not only because people don't generally know what the prerm script says and so they don't know to start the daemon so that it can be stopped by the prerm script without an error, but also because sometimes the daemons don't work or break and so you can't possibly start it. Now the way around it generally is to just chmod -x it and that is what I advise in #ubuntu. But there are a lot of people who come in there with this problem and it really shouldn't be there at all.

Either the debhelper script should be modified or not used for daemons in this way.

Revision history for this message

Sjors Gielen (sgielen) wrote on 2007-07-05:

Console output showing that this fix worked fine Edit (1.8 KiB, text/plain)

I came into #ubuntu with problems regarding vmware-player, and the chmod -x helped. Too bad you can't vote for bugs, like on bugs.kde.org, since that's something I would otherwise have definitely done for this bug.

Revision history for this message

Steve Langasek (vorlon) wrote on 2008-06-26:

Thank you for taking the time to report this issue and help to improve Ubuntu.

The behavior of debhelper here is correct; any init script which exits non-zero when trying to stop a daemon that isn't running is buggy and should be fixed. This will be clarified in an upcoming update to Debian policy, on which Ubuntu's packaging policy is based; however, this is not a change to the intent of policy, which has always been that init scripts not fail when called to stop an already-stopped process.

Note that debhelper ignoring init script failures on removal is incorrect because if a daemon could *not* be stopped for whatever reason and should have been, leaving it running after the package has been removed constitutes a potential security hole.

Changed in debhelper:
status:	New → Invalid

Revision history for this message

Sjors Gielen (sgielen) wrote on 2008-12-13:

Steve, is it correct that /etc/init.d/whatever scripts should return zero status when the daemon was already stopped?

Revision history for this message

Sjors Gielen (sgielen) wrote on 2009-09-27:

The current init.d script for tftpd-hpa uses start-stop-daemon --oknodo and the manpage for said program says:

start-stop-daemon returns 0 [...] if --oknodo is specified and [...] --stop was specified and there were no matching processes.

Therefore, its script should act normally now. Closing this bug for tftpd-hpa. It can still be used for other packages with init.d scripts which return 0 on stop when there was nothing to stop.