Bug #12061

Long delay before memory wipe starts on Stretch

Added by intrigeri 2016-12-21 18:47:47 . Updated 2016-12-22 16:10:07 .

Status:
Resolved
Priority:
Elevated
Assignee:
intrigeri
Category:
Target version:
Tails_3.0
Start date:
2016-12-21
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I think that’s a regression since I’ve bumped the APT snapshots yesterday.

Subtasks

Related issues

Related to Tails - Bug #11786: System often crashes during/after memory wipe since Linux 4.6 Duplicate 2016-09-08

History

#1 Updated by intrigeri 2016-12-21 18:48:36

  • related to Bug #11786: System often crashes during/after memory wipe since Linux 4.6 added

#2 Updated by intrigeri 2016-12-22 07:11:59

Passing --force to systemctl poweroff might help.

#3 Updated by intrigeri 2016-12-22 13:52:14

There’s no such delay when clicking the “Shutdown” button in the new Greeter.

#4 Updated by intrigeri 2016-12-22 14:25:34

I think I got it: booted with nosplash and without quiet => “A stop job is running for Session c1 of user Debian-gdm” (timeout: 1min 30s).

#5 Updated by intrigeri 2016-12-22 14:36:32 

● session-c1.scope - Session c1 of user Debian-gdm
   Loaded: loaded (/run/systemd/transient/session-c1.scope; transient; vendor preset: enabled)
Transient: yes
   Active: active (running) since Thu 2016-12-22 14:25:22 UTC; 1min 36s ago
   CGroup: /user.slice/user-114.slice/session-c1.scope
           ├─1642 gdm-session-worker [pam/gdm-launch-environment]
           ├─1791 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
           ├─1802 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/114/gdm/Xauthority -background none -noreset -keeptty -verbose 3
           ├─1888 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
           ├─1913 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
           ├─1917 /usr/bin/spice-vdagent
           └─1940 /usr/bin/pulseaudio --start --log-target=syslog

#6 Updated by intrigeri 2016-12-22 14:38:43

And after sudo systemctl stop session-c1.scope:

● session-c1.scope - Session c1 of user Debian-gdm
   Loaded: loaded (/run/systemd/transient/session-c1.scope; transient; vendor preset: enabled)
Transient: yes
   Active: deactivating (stop-sigterm) since Thu 2016-12-22 14:37:40 UTC; 20s ago
   CGroup: /user.slice/user-114.slice/session-c1.scope
           └─1802 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/114/gdm/Xauthority -background none -noreset -keeptty -verbose 3

#7 Updated by intrigeri 2016-12-22 15:41:36

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Type of work changed from Research to Code

Workaround: run systemctl --signal=SIGKILL kill session-c1.scope as root before triggering shutdown.

I’ve tried to edit session-c1.scope to lower its TimeoutStopSec and add DefaultDependencies=false (so that shutdown doesn’t block on it), but that won’t work, probably because “This is a transient unit file, created programmatically via the systemd API. Do not edit”.

So I see three options:

  • Be radical! find out why GDM’s Xorg apparently ignores SIGTERM (maybe due to sharing its -displayfd with the amnesia user’s Xorg?) => I lack the low-level skills to track this down, but it would be the best option.
  • Lower DefaultTimeoutStopSec globally in /etc/systemd/system.conf: it feels hackish, but OTOH it means that shutdown won’t ever be blocked by any buggy service that takes a while to stop, which can be seen as a safety feature in the context of Tails, since we want to wipe memory afterwards.
  • Replace our calls to poweroff with some wrapper that forcibly kills the session-c1.scope before actually running poweroff. This seems just as hackish as the previous option, without what I see as an advantage.

So I’ll go with the 2nd option.

#8 Updated by intrigeri 2016-12-22 16:10:07

  • Status changed from In Progress to Resolved
  • % Done changed from 10 to 100