Subject: Re: Bug#904558: What should happen when maintscripts fail to restart a service

From: Sam Hartman <[email-masked]>
Date: Sun, 07 Oct 2018 11:23:43 -0400

>>>>> "Simon" == Simon McVittie <[email-masked]> writes:

    Simon> the error path is most important were packages that provide a
    Simon> system-level API to other packages, so their failures are
    Simon> likely to cause other packages to fail to configure (such as
    Simon> local DNS caches and authentication services like LDAP); and
    Simon> packages that provide remote access, so their failures need
    Simon> to be fixed before a potentially remote sysadmin logs out to
    Simon> prevent the sysadmin from being locked out longer-term (like
    Simon> sshd).

As a maintainer of one of the more important packages (krb5-kdc and
krb5-admin-server), ;I'd like to chime in here.  krb5-kdc provides
enterprise level authentication and if it fails may well take out
authentication for an entire environment.

Even so,  I've found that causing upgrades to fail does far more harm
than good even for this package.

Here is my experience based on my own observations and based on bug
reports and helping people diagnose problems in krb5:

* The vast majority of failures are when krb5-kdc gets installed on a
  system where it is not actually needed, or where it was partially
  configured for  a test.  In these cases, breaking an kupgrade does
  much more harm than good.  It may break other services, because those
  services may end up in a half-configured state, so a service that is
  not critical for a given system may break critical services for that
  system.

* When krb5 is a critical service, it's failure is going to be quite
  obvious regardless of whatever the maint script does.

* It is almost always the case that debugging  the situation involves
  installing some package and that  the first thing I end up doing is
  walking a user through adding exit 0 at the top of postinst in
  /var/lib/dpkg/info before going forward.  Even if  I don't need some
  additional tool, I've been burned by other parts of the system being
  in half-configured state.

* Leaving large chunks of the system in half-configured states is about
  one of the worst things you can do for system stability.  It's not
  something we test very often, and the interactions are very difficult
  to predict.

If I understood the cause of an error in a maintainer script and knew
that it indicated a problem that the sysadmin needed to fix (and one
that likely indicated krb5 was important on this system) I would be open
to returning a failure in postinst.
In almost all other situations I'd rather simply let the service fail to
start.