** Description changed: + [Impact] + + * Unattended-upgrades.service may crash due to starting earlier than dbus and logind are up or due to logind failing to start. + * Unattended-upgrades.service not starting prevents installation of upgrades on shutdown (when u-u is configured to do that) and also prevents gracefully stopping running u-u _before_ shutdown as implemented in LP: #1803137. U-u is still stopped gracefully after the shutdown transaction is started, but that may let service restarts hang the upgrade process. + * The fix is adding an After service dependency on systemd-logind to ensure starting u-u.service after logind at least tried to start and also changing u-u-s to start even with logind's absence. + + [Test Case] + + * Stop systemd-logind and make it unable to start for example by + masking it: + + root@bb-logind:~# ln -s /dev/null /etc/systemd/system/systemd-logind.service + root@bb-logind:~# rm /etc/systemd/system/systemd-logind + root@bb-logind:~# systemctl daemon-reload + root@bb-logind:~# service systemd-logind stop + root@bb-logind:~# service systemd-logind status + ● systemd-logind.service + Loaded: masked (/dev/null; bad) + Active: inactive (dead) since Thu 2018-12-13 13:02:44 UTC; 1s ago + Main PID: 1938 (code=killed, signal=TERM) + Status: "Processing requests..." + ... + + * Run u-u-s and observe it crashing in unfixed version and starting + with falling back to polling logind instead taking the inhibition lock + at its start. + + * Restore logind's ability to start + * Restart unattended-upgrades.service + + root@bb-logind:~# systemctl daemon-reload + root@bb-logind:~# service unattended-upgrades restart + root@bb-logind:~# service unattended-upgrades status + ● unattended-upgrades.service - Unattended Upgrades Shutdown + Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2018-12-13 13:08:13 UTC; 16s ago + Docs: man:unattended-upgrade(8) + Main PID: 2079 (unattended-upgr) + Tasks: 2 (limit: 4915) + CGroup: /system.slice/unattended-upgrades.service + └─2079 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal + + Dec 13 13:08:13 bb-logind systemd[1]: Started Unattended Upgrades Shutdown. + root@bb-logind:~# systemd-analyze dot | grep unattended + ... + "unattended-upgrades.service"->"systemd-logind.service" [color="green"]; + ... + + [Regression Potential] + + * The change to service ordering is unlikely to cause any issue, but + the graceful handling of missing logind involved a small-scale + refactoring of u-u-s's code. Extensive testing did not reveal + regressions in that area, but potential bugs may cause u-u.service fail + to start and affect graceful shutdown of u-u the same way as detailed in + [Impact]. + + [Original Bug Text] + The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.7, the problem page at https://errors.ubuntu.com/problem/caf5d885046359f4857cee6c4a61e1d72d0913b1 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/.
** Changed in: unattended-upgrades (Ubuntu) Importance: Undecided => Critical ** Description changed: [Impact] - * Unattended-upgrades.service may crash due to starting earlier than dbus and logind are up or due to logind failing to start. - * Unattended-upgrades.service not starting prevents installation of upgrades on shutdown (when u-u is configured to do that) and also prevents gracefully stopping running u-u _before_ shutdown as implemented in LP: #1803137. U-u is still stopped gracefully after the shutdown transaction is started, but that may let service restarts hang the upgrade process. - * The fix is adding an After service dependency on systemd-logind to ensure starting u-u.service after logind at least tried to start and also changing u-u-s to start even with logind's absence. + * Unattended-upgrades.service may crash due to starting earlier than dbus and logind are up or due to logind failing to start. + * Unattended-upgrades.service not starting prevents installation of upgrades on shutdown (when u-u is configured to do that) and also prevents gracefully stopping running u-u _before_ shutdown as implemented in LP: #1803137. U-u is still stopped gracefully after the shutdown transaction is started, but that may let service restarts hang the upgrade process. + * The fix is adding an After service dependency on systemd-logind to ensure starting u-u.service after logind at least tried to start and also changing u-u-s to start even with logind's absence. [Test Case] - * Stop systemd-logind and make it unable to start for example by + * Stop systemd-logind and make it unable to start for example by masking it: root@bb-logind:~# ln -s /dev/null /etc/systemd/system/systemd-logind.service root@bb-logind:~# rm /etc/systemd/system/systemd-logind - root@bb-logind:~# systemctl daemon-reload + root@bb-logind:~# systemctl daemon-reload root@bb-logind:~# service systemd-logind stop root@bb-logind:~# service systemd-logind status ● systemd-logind.service - Loaded: masked (/dev/null; bad) - Active: inactive (dead) since Thu 2018-12-13 13:02:44 UTC; 1s ago - Main PID: 1938 (code=killed, signal=TERM) - Status: "Processing requests..." + Loaded: masked (/dev/null; bad) + Active: inactive (dead) since Thu 2018-12-13 13:02:44 UTC; 1s ago + Main PID: 1938 (code=killed, signal=TERM) + Status: "Processing requests..." ... - * Run u-u-s and observe it crashing in unfixed version and starting + * Run u-u-s and observe it crashing in unfixed version and starting with falling back to polling logind instead taking the inhibition lock at its start. - * Restore logind's ability to start - * Restart unattended-upgrades.service + * Restore logind's ability to start + * Restart unattended-upgrades.service - root@bb-logind:~# systemctl daemon-reload + root@bb-logind:~# systemctl daemon-reload root@bb-logind:~# service unattended-upgrades restart root@bb-logind:~# service unattended-upgrades status ● unattended-upgrades.service - Unattended Upgrades Shutdown - Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled) - Active: active (running) since Thu 2018-12-13 13:08:13 UTC; 16s ago - Docs: man:unattended-upgrade(8) - Main PID: 2079 (unattended-upgr) - Tasks: 2 (limit: 4915) - CGroup: /system.slice/unattended-upgrades.service - └─2079 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal + Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled) + Active: active (running) since Thu 2018-12-13 13:08:13 UTC; 16s ago + Docs: man:unattended-upgrade(8) + Main PID: 2079 (unattended-upgr) + Tasks: 2 (limit: 4915) + CGroup: /system.slice/unattended-upgrades.service + └─2079 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal Dec 13 13:08:13 bb-logind systemd[1]: Started Unattended Upgrades Shutdown. root@bb-logind:~# systemd-analyze dot | grep unattended ... "unattended-upgrades.service"->"systemd-logind.service" [color="green"]; ... [Regression Potential] - * The change to service ordering is unlikely to cause any issue, but + * The change to service ordering is unlikely to cause any issue, but the graceful handling of missing logind involved a small-scale refactoring of u-u-s's code. Extensive testing did not reveal regressions in that area, but potential bugs may cause u-u.service fail to start and affect graceful shutdown of u-u the same way as detailed in [Impact]. [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.7, the problem page at https://errors.ubuntu.com/problem/caf5d885046359f4857cee6c4a61e1d72d0913b1 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. + + Also seen as: + * https://errors.ubuntu.com/problem/ac61b23e0ec25a291427b875bf213fdd5b097fa5 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1806487 Title: /usr/share/unattended-upgrades/unattended-upgrade- shutdown:dbus.exceptions.DBusException(org.freedesktop.DBus.Error.TimedOut):activate_name_owner:get_name_owner:call_blocking:/usr/share /unattended-upgrades/unattended-upgrade- shutdown@373:main:__init__:get_logind_proxy:get_object:__init__:activate_name_owner:start_service_by_name:call_blocking Status in unattended-upgrades package in Ubuntu: New Bug description: [Impact] * Unattended-upgrades.service may crash due to starting earlier than dbus and logind are up or due to logind failing to start. * Unattended-upgrades.service not starting prevents installation of upgrades on shutdown (when u-u is configured to do that) and also prevents gracefully stopping running u-u _before_ shutdown as implemented in LP: #1803137. U-u is still stopped gracefully after the shutdown transaction is started, but that may let service restarts hang the upgrade process. * The fix is adding an After service dependency on systemd-logind to ensure starting u-u.service after logind at least tried to start and also changing u-u-s to start even with logind's absence. [Test Case] * Stop systemd-logind and make it unable to start for example by masking it: root@bb-logind:~# ln -s /dev/null /etc/systemd/system/systemd-logind.service root@bb-logind:~# rm /etc/systemd/system/systemd-logind root@bb-logind:~# systemctl daemon-reload root@bb-logind:~# service systemd-logind stop root@bb-logind:~# service systemd-logind status ● systemd-logind.service Loaded: masked (/dev/null; bad) Active: inactive (dead) since Thu 2018-12-13 13:02:44 UTC; 1s ago Main PID: 1938 (code=killed, signal=TERM) Status: "Processing requests..." ... * Run u-u-s and observe it crashing in unfixed version and starting with falling back to polling logind instead taking the inhibition lock at its start. * Restore logind's ability to start * Restart unattended-upgrades.service root@bb-logind:~# systemctl daemon-reload root@bb-logind:~# service unattended-upgrades restart root@bb-logind:~# service unattended-upgrades status ● unattended-upgrades.service - Unattended Upgrades Shutdown Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-12-13 13:08:13 UTC; 16s ago Docs: man:unattended-upgrade(8) Main PID: 2079 (unattended-upgr) Tasks: 2 (limit: 4915) CGroup: /system.slice/unattended-upgrades.service └─2079 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal Dec 13 13:08:13 bb-logind systemd[1]: Started Unattended Upgrades Shutdown. root@bb-logind:~# systemd-analyze dot | grep unattended ... "unattended-upgrades.service"->"systemd-logind.service" [color="green"]; ... [Regression Potential] * The change to service ordering is unlikely to cause any issue, but the graceful handling of missing logind involved a small-scale refactoring of u-u-s's code. Extensive testing did not reveal regressions in that area, but potential bugs may cause u-u.service fail to start and affect graceful shutdown of u-u the same way as detailed in [Impact]. [Original Bug Text] The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-upgrades. This problem was most recently seen with package version 1.1ubuntu1.18.04.7, the problem page at https://errors.ubuntu.com/problem/caf5d885046359f4857cee6c4a61e1d72d0913b1 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. Also seen as: * https://errors.ubuntu.com/problem/ac61b23e0ec25a291427b875bf213fdd5b097fa5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1806487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
