Instead, it goes directly to the desktop. I see network-manager resuming, which possibly means that it's suspending correctly, but not locking.
Revisions and Commits
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:
- Create a file at /etc/systemd/system/suspend@.service like so sudo nano /etc/systemd/system/suspend@.service
- 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
- 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.
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?