Osamu Aoki wrote: > My life: > 1. Dummy admin screw-up configuration and kill daemon-foo system. > 2. Try to remove everything and start from scratch > 3. dpkg -P daemon-foo > 4. error ! daemon-foo.postrm has > /usr/sbin/invoke-rc.d daemon-foo.postrm stop > while daemon-foo was dead long time ago. > No way to remove it. (See BTS #263511 as example) > > So it is good idea to use || true or || exit 0 for these scripts if > these are not in [ ... ] (update-rc.d and invoke-rc.d) > > I made a quick check and found many packaging scripts like this on my > system. Are they acceptable or we should have lintian checking them? > > Your thoughts? The current behavior is generally intended. Consider the following three scenarios: A: Stopping the daemon fails and the daemom is still running. The postinst ignores this error, purges the package, and the daemon is left running without any of its support files. Arbitrary breakage[1] may result, at a minimum you're left with a daemon running you thought you removed. B: The daemon cleans up some files when it is shut down cleanly. Typically this is pid files, but it could be much more (see mooix for one example) But last time it ran, it was not. The package is purged, and ignores the failure to stop the non-running daemon. The files are left behind on purge. C: The /etc/init.d/ thing is not a daemon at all, but some other form of service (such as provided by the ipmasq package). failure to stop such a thing can cause very unexpected behavior. There's clearly no right answer, the correct behavior of the postrm script (and the init.d script) depends on the daemon or service. The current default behavior of not ignoring failure to stop daemons in the postinst is the safest and most conservative choice; when it's wrong it's reasonably easy worked around. This is why I have closed past requests to make debhelper add || true after invoke-rc.d calls (#196952, others). On the other hand, I recently got and applied a patch to debhelper that allows you to add an arbitrary error handling function to the postrm, and do whatever is best suited to your daemon or service. -- see shy jo [1] Maybe of the cd /var/lib/daemon; rm -rf * variety. ;-)
Attachment:
signature.asc
Description: Digital signature