Hi 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 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.) Paul
signature.asc
Description: OpenPGP digital signature
