Project

General

Profile

Bug #17026

Long delay while rebooting after applying an automatic upgrade

Added by intrigeri 7 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
bugfix/17425-dont-propose-upgrading-to-running-version
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Upgrader

Description

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)
and
(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 08/31/2018
Related to Tails - Feature #17313: Tails doesn't restart after applying an automatic upgrade Confirmed
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision 9eb4be6f (diff)
Added by intrigeri 3 months ago

Avoid 2 minutes delay while rebooting after applying an automatic upgrade (refs: #17026)

Otherwise, for some reason can't be stopped while rebooting
after applying an upgrade until the default 2 minutes timeout is reached:

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

I suspect that's because the Upgrader is running via sudo as another
user, so the amnesia user's systemd instance is not allowed to kill it
and as a result, the entire session is left in running state.
OTOH this problem does not happen when the persistence setup wizard
or the Unsafe Brower is left running before rebooting; that's perhaps
because they don't run as systemd units.

Revision 7fe15625
Added by intrigeri 3 months ago

Merge branch 'bugfix/17425-dont-propose-upgrading-to-running-version' into stable (Closes: #17425, #17026)

History

#1 Updated by intrigeri 7 months ago

#2 Updated by intrigeri 7 months ago

  • 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 7 months ago

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

#4 Updated by intrigeri 4 months ago

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

#5 Updated by intrigeri 3 months ago

  • 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 3 months ago

  • 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");
     $self->fatal_run_cmd(
-        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 3 months ago

  • 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 3 months ago

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

#9 Updated by intrigeri 3 months ago

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

Also available in: Atom PDF