Your message dated Fri, 21 Apr 2006 11:31:20 -0400 with message-id <[EMAIL PROTECTED]> and subject line Bug#364023: dh_installinit prerm fails too easily has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: debhelper Version: 5.0.26 Severity: important Since the fix to #337664, the prerm code generated by dh_installinit contains: if [ -x "/etc/init.d/shishid" ]; then if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then invoke-rc.d shishid stop || exit $? else /etc/init.d/shishid stop || exit $? fi fi The problem is that most init scripts, following the standard templates, contain code like this: stop) echo -n "Stopping $DESC: " start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \ --exec $DAEMON echo "$NAME." ;; and uses set -e, which exits 1 if the daemon isn't running. If the package is new enough that both the old and the new prerm scripts contain the new dh_installinit code that checks exit status, an upgrade fails if the daemon isn't running because both prerm scripts fail. Worse, if the daemon is sufficiently broken that it cannot be started, it's almost impossible to clean up the package since both upgrades and purges fail. I had to delete the init script and then use dpkg --purge --force-remove-reinstreq. I'm not sure if the stop action should really fail if the daemon isn't running, but I expect there are a ton of init scripts out there that behave this way since it's been the template for a long time. I think the error handler for the prerm scripts installed by dh_installinit needs to be || true instead of || exit $? for stop actions (but the fix is still valid for the start actions). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages debhelper depends on: ii binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina ii coreutils [fileutils 5.94-1 The GNU core utilities ii dpkg-dev 1.13.18 package building tools for Debian ii file 4.17-1 Determines file type using "magic" ii html2text 1.3.2a-3 An advanced HTML to text converter ii perl 5.8.8-4 Larry Wall's Practical Extraction ii po-debconf 1.0 manage translated Debconf template debhelper recommends no packages. -- no debconf information
--- End Message ---
--- Begin Message ---Russ Allbery wrote: > and uses set -e, which exits 1 if the daemon isn't running. If the > package is new enough that both the old and the new prerm scripts contain > the new dh_installinit code that checks exit status, an upgrade fails > if the daemon isn't running because both prerm scripts fail. Worse, > if the daemon is sufficiently broken that it cannot be started, it's > almost impossible to clean up the package since both upgrades and > purges fail. I had to delete the init script and then use dpkg --purge > --force-remove-reinstreq. > > I'm not sure if the stop action should really fail if the daemon isn't > running, but I expect there are a ton of init scripts out there that > behave this way since it's been the template for a long time. I think the > error handler for the prerm scripts installed by dh_installinit needs to > be || true instead of || exit $? for stop actions (but the fix is still > valid for the start actions). There's nothing particularly new about dh_installinit's prerm failing if the init script fails. For years, dh_installinit did this: if [ -x "/etc/init.d/foo" ]; then /etc/init.d/foo stop fi Which, in a properly set -e script, has the same effect as the current code if the prerm fails. I've fielded probably a dozen bugs about this over the years. I have always held that if the init script is exiting nonzero, there is no assumption that debhelper can make about what's going on that will not result in buggy behavior. Maybe the daemon wasn't running before and the error is harmless. Maybe the init script failed to stop the daemon and the daemon is still running. Maybe the init script does something besides stopping the daemon without which the package cannot upgrade properly. Maybe the unstopped daemon will go haywire when files are changed out from under it if the package upgrade proceeds with it running. There's no way for debhelper to know, the only sane thing it can do is trust the init script to be well written, and propigate its errors. Policy backs me up on this, its example prerm script doesn't ignore errors. All a well-written init script has to do to avoid exiting nonzero if its daemon is not running is to add --oknodo to the start-stop-daemon call. dh_installinit also provides a way to ignore init script errors if the package maintainer knows that is appropriate in their particular case. All you have to do is run it with the --eror-handler option and provide a function in your prerm that ignores the error, and one in your postinit that, presumably, exits on error. -- see shy jo
signature.asc
Description: Digital signature
--- End Message ---
