service failures should not fail dpkg installation [was: Re: promoting virtualbox-dkms to virtualbox pre-depends]
* Jeroen Dekkers <jeroen@dekkers.ch> [150924 07:23]:
> At Wed, 23 Sep 2015 13:53:11 -0400,
> Marvin Renich wrote:
> > I think it should be documented in the developers reference that if you
> > attempt to start or restart a service in postinst, you should guard it
> > so that a failure in the service does not propagate to a failure of the
> > postinst.
>
> But then when something goes wrong when upgrading and the service
> doesn't (re)start apt/dpkg will report success but the service isn't
> running anymore. That also sounds wrong to me. Letting postinst fail
> might not be the best way to signal this, but to change that we need
> something else to let the user know that something went wrong. Just
> printing an error message isn't enough, because the user might not see
> that (for example when multiple packages are installed/upgraded and a
> later package asks some questions using dialog or when using
> unattended-upgrades).
How does failing the upgrade solve anything? The upgrade should only
fail if the failure of the service to start was because something in the
upgrade itself was broken; this is rarely the case.
There are two prominent reasons why a service fails to start after an
upgrade: the relationship between the application and its configuration
has changed (e.g. different, incompatible defaults or incompatible file
format) or some external influence that has nothing to do with the
upgrade (e.g. unavailable resource).
The first case requires the admin to sort out the changes and fix the
configuration. Being required to re-run the dpkg installation just to
flip the 'half-configured' state to 'installed' when the result would
have been the same if dpkg had not failed the first time is wrong.
In the second case, how is it a dpkg installation failure if the
hypervisor is not running so xen won't start? Everything is installed
perfectly. Or if a daemon fails to start because the ldap server on a
different host is down? Failing the installation is _really_, _really_
_wrong_!
What makes this even worse is that when installing or upgrading a large
number of packages, this kind of incorrect failure sometimes affects
many completely unrelated packages. For an unattended upgrade, this is
so much worse than having one service that (for a correct reason)
refused to restart after the upgrade.
What you are looking for is a more prominent notification that a service
did not restart. But the current situation is like the "check engine"
light flashing when you are low on fuel; yes, it gets your attention,
but it is telling you the wrong thing.
...Marvin
Reply to: