Re: service failures should not fail dpkg installation
* Paul Gevers <firstname.lastname@example.org> [150924 14:12]:
> On 24-09-15 18:21, Henrique de Moraes Holschuh wrote:
> > On Thu, 24 Sep 2015, Marvin Renich wrote:
> > What we really want is a "do not fail upgrade, BUT report that some services
> > *that were previously running* failed to restart after the upgrade run".
> > ESPECIALLY if you are going to take "unattended upgrades" seriously.
> > 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 would like to add there is more than just services. As the current
> maintainer of dbconfig-common, it is more than clear to me that updates
> of packages that require updates of (and even installs into) databases
> (tables and/or their contents) also fall into this category. If for
> whatever reason we can't connect to the database (which may even be on a
> different system), there is currently not much that we can do except
> register failure. I am currently of the opinion that if that happens,
> the package upgrade DID fail, as the package probably won't be working
> until the upgrade commands are applied with a working connection. (Just
> before people start shouting, the way dbconfig-common handles this is by
> asking the administrator if the problem should be fixed by retrying,
> ignoring the problem or considering the issue a failure. In
> noninteractive mode, the problem is ignored for installs and removals,
> but not for upgrades.)
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.
Should I open a wishlist bug against the developers reference pointing
to this discussion?