** 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
Bugs, which is subscribed to 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1806487/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to