sending USR1 to swayidle twice results in swaylock running twice?
colemickens opened this issue · 4 comments
I have swayidle configured to run swaylock -f on lock.
If I run this in zsh, then I have to unlock swaylock twice:
pkill -USR1 swayidle; pkill -USR1 swayidle
This is surprising, does swayidle queue lock events?
Okay, I accidentally had swaylock without -f setup for the timeout.
It seems surprising that USR1 triggers the timeout commands, rather than the lock command...
From looking at the code, it seems like USR1 actually schedules new commands for running on idle, and then triggers idle? And I guess those run serialized. So if I'm running swaylock without daemonizing, it's running, waiting, then running it again for the second signal?
Still, if someone can confirm this? And let me know why USR1 triggers all timeouts, rather than the lock command?
So if I'm running swaylock without daemonizing, it's running, waiting, then running it again for the second signal?
If the -w flag is passed to swayidle it indeed waits for each command to exit before executing the next. When swaylock is told to daemonize, it only forks when the session successfully locks, so you know that the session is locked before a command that turns off the display or suspend the machine.
And let me know why USR1 triggers all timeouts, rather than the lock command?
lock commands are run in response to a systemd lock event, where something is trying to lock the user session using systemd/logind interfaces. Same is the case for before-sleep commands, which are run in response to systemd events about pending system sleep.
Only timeout and resume are triggered by sway activity, and SIGUSR1 forces all timers to immediately be considered expired.
Thank you for the explanation @kennylevinsen, and the original thoughts about this on IRC a few weeks ago. I happily now have something that works to auto-lock sway on Yubikey removal, and I now understand swayidle better. Big thanks. 🙏