Re: service failures should not fail dpkg installation [was: Re: promoting virtualbox-dkms to virtualbox pre-depends]
At Thu, 24 Sep 2015 08:11:48 -0400,
Marvin Renich wrote:
> * Jeroen Dekkers <firstname.lastname@example.org> [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.
I think it solves the problem of notifying the user that something
went wrong quite clearly. Not in the correct way, I agree with that,
but the solution to that should be to notify the user in a better way,
not to stop notifying the user. Failing silently is worse than failing
in the wrong way.
> 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.
Unattended-upgrades has the MinimalSteps option that splits upgrades
in the smallest possible chunks so that isn't really a problem.
> 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.
Yes, but the way to solve that is to flash a "low on fuel" light, not
to stop notifying you and leaving you alone in the desert without
fuel. And if a "low on fuel" light isn't possible, it's better to keep
flashing the "check engine" light like it has been doing for the past