swaylock
swaylock copied to clipboard
swaywm
Unlock the screen on SIGUSR1
When the screen is locked using ext_session_lock, killing swaylock will leave the session locked. This is normally desirable if the kill is due to the OOM killer or swaylock crashing, but can be undesirable if an unlock is desired. This adds a signal handler for SIGTERM if using ext_session_lock without the --disable-unlock-on-sigterm option.
Hm, I really don't think we should unlock the screen when the OOM killer kicks in.
An explicit Sway IPC command to unlock the screen would be less dangerous.
The OOM killer generally uses SIGKILL, so it won't trigger this. However, there are other processes that might automatically send SIGTERM; changing the unlock signal to SIGUSR1 would prevent accidental unlocking.
A sway IPC command would be sway-specific; swaylock is usable on other compositors.
Right.
Can we document this new behavior in the man page? Maybe under a new SIGNALS section?
What is the use-case for the --disable-unlock-on-sigusr flag?
What is the use-case for the
--disable-unlock-on-sigusrflag?
Disabling the feature if it is unwanted. I think this was more relevant when it was on SIGTERM - with SIGUSR1 it's not likely someone will be sending it signals by accident that you would want to disable.
Disabling the feature if it is unwanted. I think this was more relevant when it was on SIGTERM - with SIGUSR1 it's not likely someone will be sending it signals by accident that you would want to disable.
I'd prefer to leave that out then if there's no clear use-case -- every CLI flag we add, we can't remove easily without breaking users.
