Page MenuHomeSolus

Screen doesn't lock when I close the lid
Closed, ResolvedPublic

Tokens
"Like" token, awarded by alecbcs."Like" token, awarded by orschiro."Like" token, awarded by valentin."Like" token, awarded by macifom."Like" token, awarded by anaknaga."Like" token, awarded by baimafeima."Like" token, awarded by Malmz."Like" token, awarded by sebkirller.
Assigned To
Authored By
cyber-doug, Sep 13 2016

Description

Instead, it goes directly to the desktop. I see network-manager resuming, which possibly means that it's suspending correctly, but not locking.

Event Timeline

Malmz awarded a token.Sep 14 2016, 6:25 AM
Malmz added a subscriber: Malmz.
DataDrake triaged this task as Low priority.Sep 24 2016, 2:08 PM

Same thing happens to me. Currently on a Lenovo ThinkPad Yoga

kirked removed a subscriber: kirked.Oct 17 2016, 2:35 PM
semper added a subscriber: semper.Nov 21 2016, 4:54 PM
anaknaga added a subscriber: anaknaga.

Other distros have struggled with this as well, see Mint. This needs a fix.

I'm not sure if this information is very useful but removing Budgie and lightdm and using Gnome 3 and gdm solves this issue completely.

macifom claimed this task.Jan 9 2017, 10:32 PM

@ChunkyPud That is helpful. Could you provide the output of systemd-inhibit --list on your working GNOME3/GDM setup?

macifom added a comment.EditedJan 10 2017, 3:52 AM

So I believe I've mostly worked out what's going on here. The way this is supposed to work is that Gnome registers an inhibitor with systemd that delays systemd-logind's suspend action on lid close. gnome-settings-daemon is registering one, but it doesn't appear to work in the absence of gdm and/or other gnome components.

auston@obsidian /usr/lib/systemd/system-sleep $ systemd-inhibit --list
     Who: auston (UID 1000/auston, PID 898/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: NetworkManager (UID 0/root, PID 615/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: auston (UID 1000/auston, PID 898/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

3 inhibitors listed.

Because Solus uses a combination of gnome-screensaver (deprecated) and lightdm, we'd need to implement lock-on-lid functionality ourselves using a systemd sleep hook like that described in the Arch PM wiki. Because we'd want to respect the user's gnome settings for screen locking some additional logic would be needed to read them out of gsettings.

How did you know all that? I'd love to know your thoughts process there. It was extremely informative

Here's a workaround for those concerned about this issue:

  1. Create a file at /etc/systemd/system/suspend@.service like so sudo nano /etc/systemd/system/suspend@.service
  2. Plop in the following:
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
ExecStart=/usr/bin/gnome-screensaver-command -l
ExecStartPost=/bin/sleep 1

[Install]
WantedBy=sleep.target
  1. Enable the service for your user with sudo systemctl enable suspend@YOURUSERNAME
macifom added a comment.EditedJan 10 2017, 8:23 AM

Looking through the source for v3.20 of gnome-settings-daemon, which is what registers and implements the systemd-inhibit hooks, I see that it does attempt to lock the screen by calling into the screensaver_proxy plugin. That proxy, however, doesn't actually proxy anything in v3.20. It implements Inhibit/Uninhibit but eats everything else like 'Lock' rather than pass the message on to the real screensaver proxy, which would forward to org.gnome.ScreenSaver and actually lock the screen.

So basically it does this:

auston@obsidian ~ $ dbus-send --type=method_call --dest=org.freedesktop.ScreenSaver  --print-reply /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver.Lock
Error org.freedesktop.DBus.Error.NotSupported: This method is not implemented

When we really want this:

dbus-send --type=method_call --dest=org.gnome.ScreenSaver  /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock

Which actually works!

Other distros are doing some crazy things to work around this. Namely rewriting the screensaver proxy plugin to actually proxy dbus method invocations to the screensaver. See Ubuntu.

@macifom It seems like a lot of progress has been made without my help but if you'd still like to see the output of that command for me, here it is:

     Who: nicky (UID 1000/nicky, PID 1061/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: NetworkManager (UID 0/root, PID 572/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

     Who: nicky (UID 1000/nicky, PID 1061/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: gdm (UID 21/gdm, PID 805/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block

     Who: gdm (UID 21/gdm, PID 805/gnome-settings-)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

     Who: GNOME Shell (UID 1000/nicky, PID 950/gnome-shell)
    What: sleep
     Why: GNOME needs to lock the screen
    Mode: delay

6 inhibitors listed.

Thank you macifom for the workaround! I have been looking for something to fix this issue, and it works great. I do hope that maybe eventually a native fix will be made for this.

Nice work, macifom. It seems to me that we need a distinction between "I'm closing the lid because I'm going to be away for a while" and "I'm closing the lid because I have external HDMIs or Thunderbolts or whatever other displays connected that I want to use instead". In the former case, we need to lock ASAP. In the latter, I would actually say that the lock countdown should be reset, because a lid closure is evidence of user activity, not unlike a keystroke or mouse movement.

I'm not saying that the proposed solution doesn't do this. I'm just trying to get clarity on proposed behavior.

valentin added a subscriber: valentin.

Hi guys,

Any update on this ? I would need this feature/setting working ...

Thanks!

I think it is worth noting that this doesn't happen when using GDM.

orschiro added a subscriber: orschiro.

I can confirm that the screen properly locks when you suspend from the menu but it fails to lock the screen when you close the laptop lid.

Is this actually a Solus or Budgie problem? If Budgie, shouldn't we better have an issue on Github?

https://github.com/budgie-desktop/budgie-desktop/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20lock%20screen%20laptop%20lid

This is great. Thanks, @ikey!