Similar condition mentioned in T527: Suspend doesn't work after 1.2.05 on XPS9350

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

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.

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

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

3. Enable the service for your user with sudo systemctl enable suspend@YOURUSERNAME

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.

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.

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!