[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: use of *-rc.d in *.{postrm,prerm} w/o || true or || exit 0

Hi, thanks Joey.

> On Thu, Aug 05, 2004 at 12:13:33AM +0200, Osamu Aoki wrote:
> > Hi, (I am not subscribed. CC me if you can.)
> ...
> > 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)
> > Your thoughts?

Joey Hess <joeyh@debian.org> wrote: 
>  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.

Oops.  ipmasq is my package.  I added "true" after bug report on me.
Hmmmm... I will change this to echo ... >&2 and as much informative 

(Actually, these should not error anymore since 2.4 and newer kertnel
 module autoloading is supported now, I think.)

This allow user to remove ipmasq and iptables and then purge ipmasq.

>  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.

Well, easy for you for sure.  But it is not easy for most non-technical
users without message telling them what to do.  I think editting
maintainer script by adding "|| true" to these calls non-trivial.

>  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.

OK.  That is fair.

I would like to see the best practice error handling to be documented
somewhere like developer-reference.

 * Do I have to make script fail? 
 * Priniting error message sufficient?

IMHO, I would like to see some unified infrastructure where we can
  dpkg -P --force-purge foo
will always purge despite some error during purge script.

Until then, it is each maintainer's descression to stop or not to stop
on such an error, I think.  Is this acceptable?


Attachment: signature.asc
Description: Digital signature

Reply to: