Project

General

Profile

Bug #12061

Long delay before memory wipe starts on Stretch

Added by intrigeri almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
-
Target version:
Start date:
12/21/2016
Due date:
% Done:

100%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

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


Related issues

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

Associated revisions

Revision 851f3e7a (diff)
Added by intrigeri almost 3 years ago

Test suite: be more patient when waiting for memory wipe (refs: #12061).

Revision 40332999 (diff)
Added by intrigeri almost 3 years ago

Test suite: make the memory wipe waiting more precise (refs: #12061).

Due to #12061, we typically wait about 90 seconds before we start wiping the
memory, so let's factor this in as an additional constant, instead of as
a multiplication factor.

Revision 66681d38 (diff)
Added by intrigeri almost 3 years ago

Lower systemd's DefaultTimeoutStopSec (refs: #12061).

session-c1.scope won't shut down before the default timeout (1min 30s),
and I didn't manage to change its timeout, nor to let shutdown.target
ignore it.

So let's change the default timeout globally. This 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. Maybe.

Revision 415a39ff (diff)
Added by intrigeri almost 3 years ago

Revert "Test suite: make the memory wipe waiting more precise (refs: #12061)."

This reverts commit 403329998fd5a1a15f53a083c47b3f9a9b7f4518.

Revision 457cc8e7 (diff)
Added by intrigeri almost 3 years ago

Revert "Test suite: be more patient when waiting for memory wipe (refs: #12061)."

This reverts commit 851f3e7a28910f913e7169a7acc87958f6afeb5a.

History

#1 Updated by intrigeri almost 3 years ago

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

#2 Updated by intrigeri almost 3 years ago

Passing --force to systemctl poweroff might help.

#3 Updated by intrigeri almost 3 years ago

There's no such delay when clicking the "Shutdown" button in the new Greeter.

#4 Updated by intrigeri almost 3 years ago

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 almost 3 years ago

● 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 almost 3 years ago

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 almost 3 years ago

  • 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 almost 3 years ago

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

Also available in: Atom PDF