Issue with systemd / suspend

[valentin2105]

Issue with systemd / suspend

[kepi]

Same issue on Arch, but this is either regression or something new. This method has been working for at least year without any issue.

I would label this as critical, as it might leave users with unlocked devices without their knowledge. It took me time to realize, that I didn't write the password and device is unlocked.

As for workaround mentioned by @valentin2105 you'd have to change env every time you reboot or restart X, which isn't really practical.

For now, I'm mittigating this with:

1. disabling systemd service betterlockscreen@myuser
2. creating system proxy service and user suspend target as mentioned in this answer on SE
3. creating user service for betterlockscreen in ~/.config/systemd/user/betterlockscreen.service

   [Unit]
   Description=Lock screen when going to sleep/suspend
   Before=sleep.target
   Before=suspend.target
   
   [Service]
   Type=simple
   ExecStart=/usr/bin/betterlockscreen --lock
   TimeoutSec=infinity
   ExecStartPost=/usr/bin/sleep 1
   
   [Install]
   WantedBy=suspend.target
   

4. systemctl --user daemon-reload && systemctl --user enable --now betterlockscreen.service

This works as user systemd session, at least on Arch linux, is updated with correct XAUTHORITY and DISPLAY on x start.

Seems like lot of work, so not sure if this is preferred solution.

Another workaround might be creating script in xinitrc, similar as arch one to update XAUTHORITY, which would set some env file which will be loaded in betterlockscreen system systemd service.

[aurkaxi]

Same issue.

[valentin2105]

I mitigated the bug by adding Environment="XAUTHORITY=/tmp/xauth_... ( need to adapt path) in my [email protected] file.

[ronit1996]

Same issue on Arch linux, is there any solution to this?

[lucasreis1]

Same here on arch too!

[rmathguy]

I have the same issue error log is as follows:

betterlockscreen@$USER.service - Lock screen when going to sleep/suspend
Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; preset: disabled)
Active: failed (Result: exit-code) since Wed 2023-10-04 12:24:18 EDT; 20min ago
Process: 138746 ExecStart=/usr/bin/betterlockscreen --lock (code=exited, status=1/FAILURE)
Process: 138747 ExecStartPost=/usr/bin/sleep 1 (code=exited, status=0/SUCCESS)
Main PID: 138746 (code=exited, status=1/FAILURE)
CPU: 62ms

Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138754]: xset: unable to open display ":0"
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138760]: Failed to open connection to "session" message bus: Usin>
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138758]: Failed to communicate with dunst, is it running? Or mayb>
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138746]: [B] Betterlockscreen
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138762]: 138674
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138762]: 138693
Oct 04 12:24:17 COMPUTER_NAME betterlockscreen[138746]: [!] i3lock already running
Oct 04 12:24:17 COMPUTER_NAME systemd[1]: betterlockscreen@$USER.service: Main process exited, code=exited, s>
Oct 04 12:24:18 COMPUTER_NAME systemd[1]: betterlockscreen@$USER.service: Failed with result 'exit-code'.
Oct 04 12:24:18 COMPUTER_NAME systemd[1]: Failed to start Lock screen when going to sleep/suspend.

Where $USER was my correct username

[Je12emy]

bump. I've playing around to see if I missed something in the configuration step, but I'm glad I'm not the only one running into this one

[Alanon202]

Not sure if this will be relevant for anyone else, but this hasn’t been an issue for me until recently, when I switched from LightDM to SDDM in search of a display manager that can run both X11 and Wayland sessions.

As is, I couldn’t get betterlockscreen to work with any of the old or new suggestions until I stopped using SDDM. I suspect that there might be peculiarities with the way SDDM starts Xsessions that is either incomplete or simply not working for my barebones Openbox config.

Regardless, starting my X11 session with LightDM again makes betterlockscreen work as it should. I’ve also begun testing greetd and although other things need work with my session config, the default betterlockscreen setup works as it should in that case as well. YMMV.