How to lock and suspend when lid closed


#21

Just tested to bind the X86Sleep on i3, it doesn’t work either. But having it locked before suspending it works.
I’m lost as well, although I would really like a solution beside doing a Win+L to lock


#22

Did you try the solution in my linked stackexchange thread?

It worked for the OP :slight_smile:


#23

Figured I’d chime in here.

What all of you want is handled by logind

cat /etc/systemd/logind.conf
# See logind.conf(5) for details.

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
HandlePowerKey=poweroff
HandleSuspendKey=ignore
HandleHibernateKey=ignore
#HandleLidSwitch=ignore
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#UserTasksMax=33%

You’ll see things like LidSwitch, SuspendKey, etc…

You’ll also see this handy little command

man logind.conf

I suggest reading the 160 lines in full.

Also note

A different application may disable logind’s handling of system power and sleep keys and the lid switch by taking a low-level inhibitor lock (“handle-power-key”, “handle-suspend-key”, “handle-hibernate-key”, “handle-lid-switch”). This is most commonly used by graphical desktop environments to take over suspend and hibernation handling, and to use their own configuration mechanisms. If a low-level inhibitor lock is taken, logind will not take any action when that key or switch is triggered and the Handle*= settings are irrelevant.

This likely applies to things like display managers, and full DE’s, not simple WM like i3, OB, etc…


#24

You are speaking of the Mod+x that allows you several options, correct?


#25

I think he binds the lock command to Mod4-l


#26

@Head_on_a_Stick Nope I didn’t so far

@chris60601 Nope, I binded directly the i3lock-fancy to $Mod+l


#27

I do not know if and what you are looking for, maybe it is useful to you.

https://bbs.archlinux.org/viewtopic.php?id=240023
Cheers


#28

So, I created a lock.service which doesn’t really work :

[Unit]
Description=Lock the screen on resume from suspend
Before=suspend.target

[Service]
User=loris
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock-fancy
ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=suspend.target

It does lock the screen after suspending, which is nice, but there is some delay before the lock triggers and it’s meh.
I’d like it to be locked before it suspends itstelf (doesn’t the before = suspend.target mean that ?)

@ector i’ll check your link tomorrow , thanks =)


#29

Mind if I ask why you might not be using the Mod+x feature? If you just wanting to invoke a lock on the fly, that whole section offers a nice bit of options from locking to reboot.

Yanno, that whole

  • Set shut down, restart and locking features
    bindsym $mod+x mode “$mode_system”
    set $mode_system (l)ock, (e)xit, switch_(u)ser, (s)uspend, (h)ibernate, ®eboot, (Shift+s)hutdown

part in i3. Just curious really :slight_smile:


#30

This is due to the sleep 1 you are adding.

Reading https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks it seems like suspend.target is the resume hook and sleep.target is the hook triggered before suspending, I could be understanding it wrong though.

/etc/systemd/system/suspend@.service


[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock-fancy

[Install]
WantedBy=sleep.target

#31

I used your .service file and it works but when I open the lid the laptop stays unresponsive as if it were off, only after pressing the power button for ~3 seconds the screen turns on and I can unlock the machine.

Really weird.


#32

Nope, even if you remove the sleep line, it’ll still take about 1 second until it will lock.

This works, but it’s not perfect… the first weird behavior is that after unlocking, the display turns off so you have to press the power button to start up the display again.
Second it locks but the laptop will not suspend :confused:

Edit: Now I get it, with that config closing the lid locks the session but the laptop will only suspend after you unlock it. Is there no way to tell the computer to suspend after locking and not after unlocking? We are getting close though.


#33

Thanks :slight_smile:


#34

It’s just an astatics thing really, the Archlabs locker looks so cool I want to use it :wink:


#35

This works for my Debian testing machine (dwm desktop):

# /etc/systemd/system/resume@.service

[Unit]
Description=Lock the screen on resume from suspend

[Service]
User=%I
Environment=DISPLAY=:0
ExecStart=/usr/bin/slock

[Install]
WantedBy=suspend.target

I started it with:

systemctl enable --now resume@empty.service

(“empty” is my user name)

/etc/systemd/logind.conf is standard:

#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes

And nothing is inhibiting the suspend or resume action:

empty@buster:~ $ systemd-inhibit --no-pager                                        
     Who: UPower (UID 0/root, PID 1452/upowerd)
    What: sleep
     Why: Pause device polling
    Mode: delay

1 inhibitors listed.
empty@buster:~ $

#37

Okey, I decided to play a little bit around and tried it with two .service files.

#1 lock@.service:
[Unit]
Description=Lock the screen on resume from suspend

[Service]
User=%I
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock-fancy

[Install]
WantedBy=sleep.target

#2 resume@.service:
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock-fancy

[Install]
WantedBy=suspend.target

Now it sometimes does exactly what it’s meant to do. After closing the lid, it first locks the session and then suspends it but sometimes it locks the session then you’ll see a quick “wrong” on the locker and the session will not get suspended…

Edit: After a couple of lid closes it now works every time :confused: I’ll look if it persists after a reboot
Edit2: Okey, it seems to be random or at least it has something to do with how quick or slow I close the lid


#38

Check the systemd journal to see what’s happening.

I would remove the Type=forking line, my resume@.service doesn’t need that at all and it may cause a race condition.


#39

Unfortunately if I change anything whatsoever it’ll go back to either just locking without suspending or suspending and only locking after resume +1 second.

It is extremely frustrating since it does work but it is inconsistent and I have no idea what is causing that or how to fix it.

The way I have it setup now with these two .service files when it works, it locks the session it’ll fail the first time then immediately succeeds afterwards and then it suspends.
If it doesn’t work it’ll just lock and not proceed to suspend.

Edit: Inconsistency only occurs if I try to lock&suspend the laptop more than once within a short period of time. First one will be successful, the second try will lock and only suspend after unlocking. After waiting a few minutes it’ll work again. Is this caused by some form of cashing?


#40

Try

journalctl -u resume@${USER}.service

&

journalctl -u lock@${USER}.service

See if there are any clues there.


#41

There are similar errors in both journals:
resume@.service

lock@.service

I’m not enough of a linux guru to know what to do with these error logs, besides that there is a problem with the i3lock and some log file…