* Revert to running unattended-upgrades.service in multi-user.target
* Trigger unattended-upgrade-shutdown actions with PrepareForShutdown()
Performing upgrades in service's ExecStop did not work when the upgrades
involved restarting services because systemd blocked other stop/start
actions making maintainer scripts time out and be killed leaving a broken
system behind.
Running unattended-upgrades.service before shutdown.target as a oneshot
service made it run after unmounting filesystems and scheduling services
properly on shutdown is a complex problem and adding more services to the
mix make it even more fragile.
The solution of monitoring PrepareForShutdown() signal from DBus
allows Unattended Upgrade to run _before_ the jobs related to shutdown are
queued thus package upgrades can safely restart services without
risking causing deadlocks or breaking part of the shutdown actions.
Also ask running unattended-upgrades to stop when shutdown starts even in
InstallOnShutdown mode and refactor most of unattended-upgrade-shutdown to
UnattendedUpgradesShutdown class. (LP: #1778219, LP: #1803137)
* Handle reverting to WantedBy=multi-user.target
* Increase logind's InhibitDelayMaxSec to 30s.
This allows more time for unattended-upgrades to shut down gracefully
or even install a few packages in InstallOnShutdown mode, but is still a
big step back from the 30 minutes allowed for InstallOnShutdown previously.
Users enabling InstallOnShutdown mode are advised to increase
InhibitDelayMaxSec even further possibly to 30 minutes.
* Cache polling result for PreparingForShutdown after it becomes true
* debian/tests/test-systemd.py: Reboot system with dbus call to honor
inhibitor locks
* Add NEWS entry about increasing InhibitDelayMaxSec and InstallOnShutdown
changes
* Stop using ActionGroups, they interfere with apt.Cache.clear()
causing all autoremovable packages to be handled as newly autoremovable ones
and be removed by default. Dropping ActionGroup usage does not slow down the
most frequent case of not having anything to upgrade and when ther are
packages to upgrade the gain is small compared to the actual package
installation.
Also collect autoremovable packages before adjusting candidates because that
also changed .is_auto_removable attribute of some of them. (LP: #1803749)
(Closes: #910874)
This bug was fixed in the package unattended-upgrades - 1.5ubuntu3.18.10.0
--------------- 18.10.0) cosmic; urgency=medium
unattended-upgrades (1.5ubuntu3.
* Revert to running unattended- upgrades. service in multi-user.target upgrade- shutdown actions with PrepareForShutd own() upgrades. service before shutdown.target as a oneshot own() signal from DBus utdown mode and refactor most of unattended- upgrade- shutdown to pgradesShutdown class. (LP: #1778219, LP: #1803137) multi-user. target yMaxSec even further possibly to 30 minutes. tdown after it becomes true tests/test- systemd. py: Reboot system with dbus call to honor
* Trigger unattended-
Performing upgrades in service's ExecStop did not work when the upgrades
involved restarting services because systemd blocked other stop/start
actions making maintainer scripts time out and be killed leaving a broken
system behind.
Running unattended-
service made it run after unmounting filesystems and scheduling services
properly on shutdown is a complex problem and adding more services to the
mix make it even more fragile.
The solution of monitoring PrepareForShutd
allows Unattended Upgrade to run _before_ the jobs related to shutdown are
queued thus package upgrades can safely restart services without
risking causing deadlocks or breaking part of the shutdown actions.
Also ask running unattended-upgrades to stop when shutdown starts even in
InstallOnSh
UnattendedU
* Handle reverting to WantedBy=
* Increase logind's InhibitDelayMaxSec to 30s.
This allows more time for unattended-upgrades to shut down gracefully
or even install a few packages in InstallOnShutdown mode, but is still a
big step back from the 30 minutes allowed for InstallOnShutdown previously.
Users enabling InstallOnShutdown mode are advised to increase
InhibitDela
* Cache polling result for PreparingForShu
* debian/
inhibitor locks
* Add NEWS entry about increasing InhibitDelayMaxSec and InstallOnShutdown
changes
* Stop using ActionGroups, they interfere with apt.Cache.clear()
causing all autoremovable packages to be handled as newly autoremovable ones
and be removed by default. Dropping ActionGroup usage does not slow down the
most frequent case of not having anything to upgrade and when ther are
packages to upgrade the gain is small compared to the actual package
installation.
Also collect autoremovable packages before adjusting candidates because that
also changed .is_auto_removable attribute of some of them. (LP: #1803749)
(Closes: #910874)
-- Balint Reczey <email address hidden> Mon, 26 Nov 2018 12:28:55 +0100