Re: service failures should not fail dpkg installation
Hallo,
* Marvin Renich [Fri, Sep 25 2015, 08:26:34AM]:
> > > Still, that would need some proper design work, and a reasonable amount of
> > > code to be written and tested. Some of it will hook into the package
> > > system, some of it needs to interface to the services subsystem (systemd,
> > > sysvinit, others).
>
> I agree, but I don't think we should wait for this feature to appear
> before fixing packages to _not_ fail upgrades when the service fails to
> start. The current situation does more harm than good.
I am wondering why this topic doesn't get more attention. For me, it
feels like being one of the top causes of breaking an upgrade process
somewhere inbetween, leaving the system in some intermediate state...
with modern APT, it has become easier to continue from this messy
situation but it's still a situation I would like to avoid.
> I agree completely. The decision on whether or not to fail the dpkg
> installation should depend on what action needs to be taken to correct
> the situation (and this is true whether we are talking about a service
> failing to start or a database upgrade failure or something else).
>
> However, most existing cases of service restart failures require
> something other than re-running the dpkg installation to fix them, and
> the default, without careful thought by the maintainer about the
> possible failure modes, should be to allow the dpkg run to succeed.
The basic idea might be that a package should be able to handle startup failures in
different categories (and resolution strategies), defined by
maintainers. However, it's not so easy because of subsequent errors that
might happen in other services far way in the dependency chain, and it's
hard to predict them all.
We need some compromise here. Something I imagine is:
a) packages that participate in the "error-tolerant" scheme get some
attribute set. They also run delicate commands through a wrapper command
that collects the failure/success state and records TODO tickets in some
global configuration file.
b) apt might add additional hints to the package installation, letting
maintainer scripts know whether there are dependent packages somewhere
in the chain.
c) for failed tasks, dpkg and apt frontends show the user messages
"there are things to fix that require your attention: <list of issues>",
and when the admin solved the problem, he can close the ticket with the
imaginary tool.
> Should I open a wishlist bug against the developers reference pointing
> to this discussion?
Feel free.
Best regards,
Eduard.
Reply to: