Margarita Manterola writes ("Bug#904558: What should happen when maintscripts
fail to restart a service"):
> Sorry that it took so long to get back to this bug. The other bug took
> all the attention.
...
> If a postinst fails (for whatever reason), the package is left in a
> broken state (Failed-Config) which in general makes the package
> management system unhappy.
The other effect is that the package's dependencies are not
configured, so their postinsts do not experience a broken situation.
> It seems that the only reason why one may want to do this is to call
> the attention of the sysadmin so that they can solve the problem.
> However, in a world where a large number of users are running automatic
> updates, leaving the package management system in a broken state is
> pretty sad, not very visible and rather confusing for the user when
> they finally encounter it.
>
> Is there an another use case for leaving the package in Failed-Config
> that we missed?
If you deliberately cause the postinst to succeed when the package is
nonfunctional, then the package's r-dependencies will be configured
(ie have their postinsts run) in the broken state.
The r-dependencies' postinsts may then do wrong things. They may
leave the r-dependencies in anomalous states. If one takes the
argument you make above to its logical conclusion, all those postinsts
should also report success.
The result is system where the only thing that is happy is the package
management systme, and the records of the root cause of the problem,
and how the failed operations might be reattempted, have been lost.
I guess you will infer from what I write above that "reporting errors
causes the next layer to be unhappy", and "reporting errors causes the
user to be unhappy" to be extraordinarily bad arguments.
There may be good reasons not to treat daemon startup failure as a
postinst failure, but the argument above is not one of them.
> It's unclear why the service (re)start needs to be a special case.
Service (re)starts are more likely to fail for unrelated reasons.
Also some packages are able to provide much of their intended API even
without the daemon.
I think the general rule of thumb should be that a daemon startup
failure should be treated as a configuration failure.
I'm content with a situation where maintainers Feel free to diverge
from this if there are reasons to do so.
> I personally think that it would make sense for the policy to at least
> recommend what should happen with regards to maintainer scripts and
> typical operations that are performed in them.
There is already a section on error handling in scripts, which (IMO
correctly) says that shell scripts should use set -e.
When I wrote that, it didn't occur to me that anyone would think that
a failure by a postinst script to perform an intended operation should
be treated any other way than a failure of the postinst script.
(In the usual case. There are of course lots of situations where the
right approach is some kind of error recovery, or the operation was
attempted "just in case", or something, in which case more subtle
error handling is called for.)
> And, while I'm open to be convinced otherwise, I don't see any benefit
> from postinst (particularly postinst + configure) ever failing.
Frankly I'm disturbed to be reading this, here. See above.
If the postinst fails, then the user has the opportunity to fix the
root cause and rerun dpkg-source --configure --pending. That will
then repair the system completely.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
