Bug #17026

Long delay while rebooting after applying an automatic upgrade

Added by intrigeri 2019-09-06 05:38:58 . Updated 2020-01-13 08:13:51 .

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


This got reported for the 4.0~beta1 → 4.0~beta2 upgrade. I don’t know yet if 3.x is affected.

User report:

The behavior that the first shutdown after the incremental upgrade takes
much longer was there again.
I pressed Esc and its one line which is constantly changing between:

(1 of 2) A stop job is running for User Manager for UID 112 ( x / 2 min)
(2 of 2) A stop job is running for User Manager for UID 1000 ( x / 2 min)

The x is counting up till 1 min 30 s then:
[ok] Stopped User Manager for UID 112.

and the shutdown process is going on.

On every other shutdown the whole shutdown process is done after a few
seconds but after an incremental update it takes minimum one and a half
minutes so i think at least after an upgrade the user should see that his
computer isnt done with shutting down after a few seconds.


Related issues

Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements In Progress 2018-08-31
Related to Tails - Feature #17313: Tails doesn't restart after applying an automatic upgrade Confirmed
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed


#1 Updated by intrigeri 2019-09-06 06:12:47

#2 Updated by intrigeri 2019-09-12 12:35:26

  • Target version deleted (Tails_4.0)

UID 112 is Debian-gdm so I was tempted to blame the crazy GDM hacks I’ve introduced in 4.0~beta2. Except this problem happens while still running 4.0~beta1, so this can’t be the explanation.

Besides, the user says “was there again”, which suggests they’ve seen the problem in earlier automatic upgrades. Given that’s the first time we offer automatic upgrades on 4.x, it implies they’ve seen it on 3.x ⇒ not a regression and not a 4.0 release blocker.

Regardless, something wrong is happening that makes user\112.service@ take 1.5 minutes to stop. Next step to investigate this would be, after applying an automatic upgrade but before restarting, to:

  • check what’s running in this CGroup
  • try to stop user\112.service@ manually and see what part of it does not stop quickly

#3 Updated by intrigeri 2019-09-12 12:35:57

  • related to Feature #14544: Spend software developer time on smallish UX improvements added

#4 Updated by intrigeri 2019-12-12 07:58:17

  • related to Feature #17313: Tails doesn't restart after applying an automatic upgrade added

#5 Updated by intrigeri 2020-01-11 07:49:22

  • Assignee set to intrigeri
  • Feature Branch set to bugfix/17026-rebooting-after-upgrading-takes-ages

Just a hunch I should check.

#6 Updated by intrigeri 2020-01-11 12:44:46

  • Assignee deleted (intrigeri)
  • Feature Branch deleted (bugfix/17026-rebooting-after-upgrading-takes-ages)

I’ve tried this:

--- a/config/chroot_local-includes/usr/src/iuk/lib/Tails/IUK/Frontend.pm
+++ b/config/chroot_local-includes/usr/src/iuk/lib/Tails/IUK/Frontend.pm
@@ -720,7 +720,11 @@ method do_incremental_upgrade (HashRef $upgrade_path) {
 method restart_system () {
     $self->info("Restarting the system");
-        cmd       => ['/sbin/reboot'],
+        # Avoid creating a reboot(8) subprocess that would be in the scope
+        # of the amnesia user's session, which could block the reboot
+        # until a timeout is reached, due to the circular dependency
+        # this would introduce
+        cmd       => ['/bin/systemctl', 'reboot'],
         error_title => $self->encoding->decode(gettext(
             q{Error while restarting the system}

But it did not help.

FWIW, during the 4.2 → 4.2.1 upgrade, I only see the reboot blocked by UID 1000, not by UID 112.

#7 Updated by intrigeri 2020-01-12 11:21:28

  • Status changed from Confirmed to In Progress
  • Assignee set to intrigeri
  • Target version set to Tails_4.2.2
  • Feature Branch set to bugfix/17425-dont-propose-upgrading-to-running-version
  • Type of work changed from Research to Code

#8 Updated by intrigeri 2020-01-12 12:21:14

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

#9 Updated by intrigeri 2020-01-13 08:13:51

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:tails|7fe156258d457f684707e3d4bd0cb6ddb05b343c.