Hi,
Sorry that it took so long to get back to this bug. The other bug took
all the attention.
On 2018-07-25 06:07, Sean Whitton wrote:
If postinst or one of the other scripts does a service restart and
the restart operation fails, should the postinst abort or should it
mask the error, continue and return success?
We had some discussion around this subject at the past ctte meeting [1],
and after some back and forth we came to the conclusion that in general
it's a bad idea for any postinst to purposely fail, regardless of
whether it was trying to (re)start a service or not.
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.
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?
[1]:
https://salsa.debian.org/debian/tech-ctte/blob/master/meetings/20180815/debian-ctte.2018-08-15.log.txt
As a Policy delegate I want to move this issue along, and I can see
three ways of doing that:
1. write a patch to explicitly state in Policy that what happens when a
service (re)start fails in a maintscript is left up to package
maintainer discretion, and close the bugs
2. make a further attempt to establish consensus on a requirement that
maintscripts are consistent in the case of a (re)start failure (this
is the default option, so to speak, and I cannot see it succeeding)
3. ask the T.C. to decide what maintscripts should do in these cases.
It's unclear why the service (re)start needs to be a special case. Any
operation that is performed in a postinst might fall under the same
question of what should happen when that operation fails. Operations
like
creating users, creating directories, changing permissions, running a
command to update the contents of a file, and so on.
The general question about which I am seeking advice: does the
T.C. think that Debian can be consistent on service (re)starts in
maintscripts, or is the best we can do to leave it up to package
maintainer discretion?
We didn't reach this point in our discussion, so this is still an open
question.
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.
And, while I'm open to be convinced otherwise, I don't see any benefit
from postinst (particularly postinst + configure) ever failing.
If the only reason for postinst to fail is so that the user knows what
happened, we should devise a better mechanism for informing the user
about the failure.
--
Regards,
Marga
