Bug#801065: Documenting how to not fail postinst on service fails to start

[Wouter Verhelst <wouter@debian.org>]

On Wed, Feb 15, 2023 at 02:38:10PM -0500, Marvin Renich wrote:
> > > >  - the service fails to start in the postinst.
> 
> This implies that "the service is running" is part of "the service is
> configured", which is where I disagree.

What Steve said is that if

- The service fails to start, *AND*
- The service was previously running (or this is a new install)

*THEN*

this is something that should make postinst fail.

The two preconditions are linked, and should not be looked at
separately.

If the service was *not* previously running, then that is a different
situation.

But if the service was previously running and now a restart fails, then
obviously[1] this is a problem with the upgrade that should be looked at
by the admin, which means it must be flagged to the admin somehow.

As I mentioned in the TC discussion, one can reasonably debate what the
best way is to flag such problems, but I think it's not reasonable to
say "let's just push it under the mat, it doesn't matter".

We currently only have one sure way of telling the admin that there is a
problem, and that is "fail postinst".

As such, I think any suggestion that we ignore a restart failure of a
service that was running before the dpkg run should be accompanied by a
plan on *how* to flag this failure to the admin in a way that the admin
will know that things failed. In the absence of that, the status quo of
"postinst should fail on a restart of a service" should probably be
retained.

[1] barring extreme corner cases of the style "the admin made broken
    changes but forgot to try a restart"

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.