Project

General

Profile

Bug #11052

Do not suspend when closing lid

Added by elouann over 3 years ago. Updated about 1 month ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
05/03/2016
Due date:
% Done:

0%

Feature Branch:
bugfix/11052-do-not-suspend-when-closing-lid
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

Closing the lid suspends to RAM, and inhibits the emergency shutdown.
This can be fixed with the following steps:

sudo vim /etc/systemd/logind.conf
set HandleLidSwitch to 'ignore'
systemctl restart systemd-logind

I've tried to submit a patch, but "git grep logind.conf" reads

config/binary_rootfs/squashfs.sort:etc/systemd/logind.conf

I stopped here, as I don't know how to access such a path


Related issues

Related to Tails - Bug #8071: Should not suspend to RAM when closing lid on battery power Resolved 10/11/2014
Related to Tails - Feature #14556: Show a suspend to RAM button in the status menu Resolved 08/30/2017
Related to Tails - Bug #12597: Recover ticket deleted by mistake: #11395 Duplicate 05/25/2017
Related to Tails - Feature #10553: Add "Don't ask me again" option to notifications where appropriate Confirmed 11/16/2015
Related to Tails - Bug #16787: Trigger emergency shutdown on resume when the boot device is missing Confirmed

Associated revisions

Revision 101ec819 (diff)
Added by elouann 4 months ago

Disable suspend when closing lid. #11052

Revision f1769ffb (diff)
Added by segfault 4 months ago

Check whether option to disable suspend on lid close was set (refs: #11052)

Revision 28cf5d75 (diff)
Added by segfault 4 months ago

Check whether option to disable suspend on lid close was set (refs: #11052)

History

#1 Updated by elouann over 3 years ago

  • Related to Bug #8071: Should not suspend to RAM when closing lid on battery power added

#2 Updated by sajolida over 3 years ago

  • Status changed from New to Confirmed
  • Type of work changed from Code to Discuss

I think it's cool to be able to suspend Tails. I used to do this all the time manually in 1.x (for example, to put my laptop in my bag without heating too much or waisting the battery).

Yet, whether this should be the default is a good question, for example because as you're pointing out it disables the emergency shutdown.

Still, if while Tails is suspended I remove my USB stick, then any attempt to open the lid triggers the emergency shutdown. So the emergency shutdown is not disabled but only postponed. This could be problematic if facing an attacker ready to do a cold boot attack or able to read the RAM somehow with the lid closed down, but it's not problematic otherwise.

We could change the default from "suspend" to "not suspend" and still give an option to suspend in a different way (like we had in 1.x though it was not advertised) but then the situation would remain equally problematic if people find it cool to suspend, do it all the time, and then one day face an adversary that can do cold boot attacks.

Marking this as a discussion then.

#3 Updated by sonicsnail over 3 years ago

I've been having issues with suspend too. If I never close the lid, Tails shuts down as normal and emergency shutdown works fine too. But if I close the lid (suspend) and re-open it, and then attempt to shut down, Tails gives errors and doesn't shut down and doesn't wipe the memory; emergency shutdown doesn't work after suspending either. Also, sometimes after suspending, Tails is frozen for about 30 seconds. None these problems existed on Tails 1.X because suspend was disabled.

Part of this is probably because I'm using an Acer C720 chromebook, which is known for having suspend issues on linux. A fix is documented here, along with the same errors I've been getting: http://www.circuidipity.com/c720-chromebook-to-jessiebook.html#suspend

#4 Updated by sonicsnail over 3 years ago

I think what sajolida is talking about relates to a tradeoff between security and convenience. While it's convenient to be able to suspend Tails, it disables a security mechanism. In my opinion, Tails should be secure by default, and if it's not possible to fix suspend so emergency shutdown works all the time, no matter what, then we shouldn't be suspending. The nature of emergencies is that you can't predict when they'll happen, which is why safety mechanisms need to be reliable and always ready for immediate use.

Worst case scenario: if the default were to suspend, and if attackers managed to do a cold boot attack on a user's suspended Tails system after the user removed the USB drive (mistakenly thinking that emergency shutdown would activate), Tails could be blamed for having insecure defaults.

So I think "not suspend" should be the default, and if necessary there could be an option to enable suspend (or documentation on how to do this) but with a warning that it disables emergency shutdown. That way, if users find it convenient to manually enable suspend all the time, they do so accepting the increased risk.

#5 Updated by elouann over 3 years ago

Suspend seems to freeze some devices:

MacBookPro12,1

Exact steps to reproduce the error
----------------------------------
Close and open laptop lid

Actual result and description of the error
------------------------------------------
Cursor is frozen and Tails apparently cannot be accessed without some way to un-freeze it. Computer must be restarted for functionality to reappear.

Cursor is frozen even if mouse and/or trackpad are functional by themselves (ex. light glowing on USB mouse)

#6 Updated by elouann over 3 years ago

Another bug report related to suspend on lid

Subject: unwanted suspend-to-ram during using actively tails 2.0.0 and 2.0.1

Exact steps to reproduce the error
----------------------------------
During active working the system falls in suspend-to-ram.
reativating, awaking without any errors, but it falls back to suspend-to-ram in few seconds.

This happens with a samsung x20-notebook, that causes no problems with debian-distribution now for several years...
No problems with various distributions and live-systems.

No problem with tails in all versions now for more than one year.
This problem appeared in tails 2.x for the first time.

#7 Updated by segfault about 3 years ago

  • Assignee set to segfault
  • Type of work changed from Discuss to Code

In the monthly meeting we decided to not suspend when closing the lid.

#8 Updated by volenta almost 3 years ago

Yo,

This sed one-liner in config/chroot_local-hooks/48-disable-suspend-when-closing-lid will do the trick :

sed -i --regexp-extended 's/^#?HandleLidSwitch=.*/HandleLidSwitch=ignore/' /etc/systemd/logind.conf

:)

#9 Updated by elouann almost 3 years ago

  • Status changed from Confirmed to In Progress
  • QA Check set to Ready for QA
  • Feature Branch set to elouann:bugfix/11052-do-not-suspend-when-closing-lid
  • Type of work changed from Code to Test

Thanks volenta, this is now in a branch and ready for testing

#10 Updated by intrigeri almost 3 years ago

  • Assignee changed from segfault to anonym
  • Target version set to Tails_2.6
  • Type of work changed from Test to Code

(This can't be "Ready for QA" and "Type of work = Test" at the same time. I don't expect the branch authors to be able to test it themselves, but the fix is simple enough, so let's fix the semantics by pretending it's a "ready for QA" code ticket.)

#11 Updated by sajolida almost 3 years ago

  • Assignee changed from anonym to segfault
  • Target version deleted (Tails_2.6)

This ticket has a subtask #11395 which is not tackled yet, so I don't want to apply this change in 2.6 until #11395 is solved. Reassigning this ticket to segfault, who's the owner of #11395 and should check how this patch fits in his plans for #11395.

#12 Updated by segfault almost 3 years ago

It seems like #11395 is blocked by #11729. I don't have time to fix #11729 any time soon, so if no one else does, #11395 won't happen any time soon. Because #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.

#13 Updated by intrigeri about 2 years ago

  • QA Check deleted (Ready for QA)

(There's a remaining subtask.)

#14 Updated by intrigeri almost 2 years ago

  • Related to Feature #14556: Show a suspend to RAM button in the status menu added

#15 Updated by u 11 months ago

segfault wrote:

It seems like #11395 is blocked by #11729. I don't have time to fix #11729 any time soon, so if no one else does, #11395 won't happen any time soon. Because #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.

#11395 seems to be the ticket that has accidentaly been deleted so it's not clear what you are talking about :(
See https://labs.riseup.net/code/issues/12597

#16 Updated by u 11 months ago

  • Related to Bug #12597: Recover ticket deleted by mistake: #11395 added

#17 Updated by segfault 4 months ago

u wrote:

segfault wrote:

It seems like #11395 is blocked by #11729. I don't have time to fix #11729 any time soon, so if no one else does, #11395 won't happen any time soon. Because #11729 also effects the suspend-to-RAM caused by closing the lid, I think we should apply this patch and prevent the suspend on lid closing.

#11395 seems to be the ticket that has accidentaly been deleted so it's not clear what you are talking about :(
See https://labs.riseup.net/code/issues/12597

For the record: #11395 was about showing the suspend button, the new ticket for this is #14556.

#18 Updated by segfault 4 months ago

  • Assignee deleted (segfault)
  • QA Check set to Ready for QA
  • Feature Branch changed from elouann:bugfix/11052-do-not-suspend-when-closing-lid to bugfix/11052-do-not-suspend-when-closing-lid

This still seems to work. I pushed another commit which checks whether the `sed` statement succeeded in adding the option, so that the we notice if the logind.conf content is changed in the future and the pattern doesn't match anymore.

Optimistically setting to ready for QA because the only subtask is also ready for QA.

#19 Updated by intrigeri 4 months ago

  • Assignee set to intrigeri
  • Target version set to Tails_3.14

segfault wrote:

Optimistically setting to ready for QA because the only subtask is also ready for QA.

@segfault, there's no subtask currently. I guess you meant #14556. Anyway, I trust you this is ready and I'll review it.

#20 Updated by segfault 4 months ago

intrigeri wrote:

segfault wrote:

Optimistically setting to ready for QA because the only subtask is also ready for QA.

@segfault, there's no subtask currently. I guess you meant #14556. Anyway, I trust you this is ready and I'll review it.

Right, #11395 was the subtask until it got accidentally deleted and replaced by #14556.

#21 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to segfault
  • QA Check changed from Ready for QA to Dev Needed

@segfault, what about dropping a /usr/lib/systemd/logind.conf.d/*.conf file instead? This would be consistent with how we use for example /usr/lib/tmpfiles.d and would move a bit towards "/etc is for local overrides and derivatives". Now, I see that we have config/chroot_local-hooks/31-lower-DefaultTimeoutStopSec and config/chroot_local-hooks/32-logind-NAutoVTs, so this would trade one bit of consistency for another… unless we port these 2 hooks to drop-in config file snippets too.

#22 Updated by segfault 4 months ago

  • Assignee changed from segfault to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

@segfault, what about dropping a /usr/lib/systemd/logind.conf.d/*.conf file instead? This would be consistent with how we use for example /usr/lib/tmpfiles.d and would move a bit towards "/etc is for local overrides and derivatives". Now, I see that we have config/chroot_local-hooks/31-lower-DefaultTimeoutStopSec and config/chroot_local-hooks/32-logind-NAutoVTs, so this would trade one bit of consistency for another… unless we port these 2 hooks to drop-in config file snippets too.

I ported all three hooks to config files.

  • The system still doesn't suspend when the lid is closed (tested on one machine, a different one than last time)
  • The NAutoVTs config seems to work, VT5 still does not start a TTY when I switch to it via Ctrl+Alt+F5
  • systemctl show shows that the DefaultTimeoutStopSec option was applied as well.

#23 Updated by intrigeri 4 months ago

Code review passes, will build & test.

#24 Updated by intrigeri 4 months ago

  • Assignee changed from intrigeri to sajolida
  • QA Check changed from Ready for QA to Info Needed

Hi sajolida! I've just merged the branch for #11729 and #14556, so that 1. emergency shutdown is not triggered anymore when resuming from suspend; 2. we display a button to suspend to RAM in the GNOME UI. And I'm now wondering what to do here. It seems to me that we decided to disable suspending when closing the lid for two reasons:

  • We thought we would be able to do that before we fixed #11729. But actually #11729 is now a solved problem.
  • We were concerned that users would not be conscious that they are disabling emergency shutdown when they close the lid. That seems a valid concern but it feels inconsistent with the fact we just made suspending easier (exposed in the GNOME UI):
    • I'm pretty sure many users won't be conscious they're disabling emergency shutdown when they click the "Suspend" button in GNOME. So I wonder why it's a bigger deal that they're not conscious about this when closing the lid.
    • Disabling one of the best known ways to suspend to RAM (closing the lid) seems to go backwards wrt. our desire to make suspending to RAM easier.

So I'm not sure that merging this branch is the right thing to do now. What do you think?

@segfault, I cherry-picked 28ef46f6b5b9a407c0b61c1aec9432fb4ea17e1f as d71b9fabd45d74eb5b60350aae59f063d25ba36c, amended it to drop the part that was specific to this branch, kept the nice refactoring which is orthogonal to this branch, and pushed to stable etc.

#25 Updated by intrigeri 3 months ago

@segfault, we should probably not merge this before https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919914 is fixed in Buster: otherwise we would need to revert it and change users' expectations again in just a few months.

#26 Updated by sajolida 3 months ago

  • Related to Feature #10553: Add "Don't ask me again" option to notifications where appropriate added

#27 Updated by sajolida 3 months ago

  • Assignee changed from sajolida to intrigeri
  • QA Check deleted (Info Needed)

Like I argued in #11052#note-2, I'm not convinced that changing the default and not suspending when closing the lid will prevent cold-boot attacks for people:

We could change the default from "suspend" to "not suspend" and still give an option to suspend in a different way (like we had in 1.x
though it was not advertised) but then the situation would remain equally problematic if people find it cool to suspend, do it all the
time, and then one day face an adversary that can do cold boot attacks.

We don't have the logs of the meeting in which we decided to not suspend when closing the lid (#11052#note-7, "almost 3 years ago") but this decision seems to be older than #11729 ("over 2 years ago"). So I'm a bit reluctant to override this decision without knowing how and why we made it.

I'm not sure what to do now even though my personal preference would be to suspend when closing the lid.

If other people still feel strongly in favor of not suspending when closing the lid, another solution could be to inform users about how emergency shutdown related to suspension to RAM the first time they click on the "Suspend" button in GNOME. This would require #10553.

#28 Updated by intrigeri 3 months ago

We don't have the logs of the meeting in which we decided to not suspend when closing the lid (#11052#note-7, "almost 3 years ago") but this decision seems to be older than #11729 ("over 2 years ago").

Indeed, we don't have the full logs; we have only this in the meeting minutes:

# [[!tails_ticket 11052 desc="Do not suspend when closing lid "]]

- Coming back from suspend breaks sometimes on some hardware.
- But suspend disables emergency shutdown (until the lid is open again)
and some people might be surprised by this.

So we want to support both options and thus what makes more sense is to
add an option to suspend from the system menu through some button,
keyboard shortcut, or a combination of both. Hypothesis are:

- Replace the "Restart" button with a "Suspend" button. That's more
visible.
- Change "Restart" or "Power Off" into "Suspend" when pressing "Alt".
That's more like the default in GNOME.
- Have an additional and dedicated button for "Suspend". But we might
add yet another button for the screen locker.

Regarding "Coming back from suspend breaks sometimes on some hardware": this was reported for exactly one laptop, more than 3 years ago, while we've had suspend-on-lid-close enabled for years. There's a good chance some upgrade fixed that since. I've not seen this happen on non-Tails Debian systems around me for many years. So I don't think this is a strong argument nowadays.

Regarding "suspend disables emergency shutdown (until the lid is open again)": this seems to be the only relevant argument in favour of disabling suspend-on-lid-close. Let's focus on this one.

So I'm a bit reluctant to override this decision without knowing how and why we made it.

I'm on the same page but I see no way to know now more precisely how and why we made it, so the best we can do is to glean whatever hint we can in these meeting minutes, tickets history, which we did already :/

I'm not sure what to do now even though my personal preference would be to suspend when closing the lid.

Same here. Let's also keep in mind that we've had suspend-on-lid-close enabled for years and I'm not aware of anyone raising serious concerns/issues with it since we discussed this 3 years ago. So perhaps it's not such a big deal.

I'll propose on tails-dev@ that we keep suspend-on-lid-close enabled, so whoever has a strong opinion about it has room to express it.

#29 Updated by intrigeri 3 months ago

  • Target version changed from Tails_3.14 to Tails_3.15

intrigeri wrote:

I'll propose on tails-dev@ that we keep suspend-on-lid-close enabled, so whoever has a strong opinion about it has room to express it.

Done, should appear on https://lists.autistici.org/list/tails-dev.html shortly (use "Jump!" to today's date if you read this after the post is not on the archives' front page anymore).

I'll wait a few weeks and will then update this ticket accordingly, be it by merging the branch, by rejecting it, or whatever we'll decide.

#30 Updated by intrigeri 3 months ago

  • Type of work changed from Code to Discuss

#31 Updated by segfault 3 months ago

Regarding "Coming back from suspend breaks sometimes on some hardware": this was reported for exactly one laptop, more than 3 years ago, while we've had suspend-on-lid-close enabled for years. There's a good chance some upgrade fixed that since. I've not seen this happen on non-Tails Debian systems around me for many years. So I don't think this is a strong argument nowadays.

I guess that "Coming back from suspend breaks" was caused by #11729. I've seen #11729 myself repeatedly on at least two different laptops, the hardware I used to debug #11729 was affected in about 1 out of 3 cases. If this issue occurs similarly frequently on most hardware, a lot of users would have been affected by it. That would again be a hint that "we don't get many bug reports" does not equal "not many users are affected".

Regarding "suspend disables emergency shutdown (until the lid is open again)": this seems to be the only relevant argument in favour of disabling suspend-on-lid-close. Let's focus on this one.

I agree.

Let's also keep in mind that we've had suspend-on-lid-close enabled for years and I'm not aware of anyone raising serious concerns/issues with it since we discussed this 3 years ago. So perhaps it's not such a big deal.

Note that in order to fix #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was unplugged while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is unplugged during suspend.
We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.

#32 Updated by intrigeri about 2 months ago

segfault wrote:

Note that in order to fix #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was plugged out while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is plugged out during suspend.

Right.

We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.

This would be sweet, but I'm not 100% sure we can do that in a way that does not cancel the fix for #11729 (e4e7f81288ff9723b94ec434bbc7006ce240cb0f) and reintroduce that problem on affected hardware. I'm not sure because I don't fully understand what exact behaviour caused #11729. If we assume that the emergency shutdown was triggered while suspending, queued, and actually executed while resuming, we should be fine. If OTOH the reason for #11729 is a about a more complex (and racy) situation, then there's a chance that when we implementing this, we find out that it's hard to tell when exactly we can check "if the device is not found": if we check too early, then possibly the system hasn't re-discovered that device yet, or something like that.

#33 Updated by intrigeri about 2 months ago

I've made an updated proposal, which integrates segfault's great idea, on tails-dev@. I'll come back to it in a few weeks.

#34 Updated by intrigeri about 2 months ago

  • Target version changed from Tails_3.15 to Tails_3.16

#35 Updated by segfault about 2 months ago

intrigeri wrote:

segfault wrote:

Note that in order to fix #11729, I disabled the udev-watchdog during suspend. Previously, the system would emergency shutdown on resume if the Tails device was plugged out while the system was suspended. That will not be the case anymore, the system will keep running if the Tails device is plugged out during suspend.

Right.

We could work around this by adding an extra check for the boot device on resume, which will trigger the emergency shutdown if the device is not found.

This would be sweet, but I'm not 100% sure we can do that in a way that does not cancel the fix for #11729 (e4e7f81288ff9723b94ec434bbc7006ce240cb0f) and reintroduce that problem on affected hardware. I'm not sure because I don't fully understand what exact behaviour caused #11729. If we assume that the emergency shutdown was triggered while suspending, queued, and actually executed while resuming, we should be fine. If OTOH the reason for #11729 is a about a more complex (and racy) situation, then there's a chance that when we implementing this, we find out that it's hard to tell when exactly we can check "if the device is not found": if we check too early, then possibly the system hasn't re-discovered that device yet, or something like that.

True, but we should be able to work around that with by waiting a few seconds after resuming before checking the device.

I would implement this by putting another script in /lib/systemd/system-sleep which, on resume, sleeps a few seconds and then checks whether the boot device is there, and shuts down if it's not. We could reuse the functions from udev-watchdog-wrapper for that (which we should then extract into tailslib), although I'm not sure whether the current implementation of boot_device() works in the case that the boot device was removed.

#36 Updated by sajolida about 2 months ago

Yes, we should definitely shutdown if the Tails device is unplugged while the computer is suspended!

#37 Updated by sajolida about 2 months ago

We decided on http://lists.autistici.org/message/20190515.110800.2c7b5109.en.html that we want to keep suspending when closing the lid.

as intrigeri wrote: It may be nice to provide a way to somehow tell Tails "I'm going to
close the lid but please don't suspend, because I want to keep the
system up and able to trigger emergency shutdown if I unplug the Tails
device".

This is a new feature request with a tiny target user base and we're not
interested in putting much energy into it.

#38 Updated by intrigeri about 1 month ago

  • Related to Bug #16787: Trigger emergency shutdown on resume when the boot device is missing added

#39 Updated by intrigeri about 1 month ago

Yes, we should definitely shutdown if the Tails device is unplugged while the computer is suspended!

See you on #16787 then :)

#40 Updated by intrigeri about 1 month ago

  • Status changed from In Progress to Rejected

We decided on http://lists.autistici.org/message/20190515.110800.2c7b5109.en.html that we want to keep suspending when closing the lid.

I initially meant to give folks a little bit more time to comment on my updated proposal on tails-dev@, instead of considering this as a decision already. Anyway, let's reopen if they do :)

Also available in: Atom PDF