xflock4 gets stuck in unlock/lock cycle with some setups
I upgraded to Debian Trixie, and it looks like 42db188a912413d099150dd9f44f008285c8a493 changed the behaviour of the screen lock. Previously, multiple runs of xflock4 were asynchronous - if xflock4 were run when the screen was already locked, then the lock command would be executed immediately, and the screen would remain locked. Now, xflock appears to make a synchronous call, which blocks until complete, and any more runs while the screen is locked will also block, but then be executed *after* the original call unblocks. This results in an "unlock/lock" loop with setups using tools like xautolock: - `xautolock -time 5` calls xflock4 every 5 minutes when there is no keyboard/mouse activity - so if screen is locked for an hour, xautolock will run xflock4 12 times - first xflock4 locks the screen - the next 11 runs block and can only lock the screen after the user unlocks it This change may be deliberate, and if so, it's not hard to workaround, but it does break some existing setups so maybe it should be considered a bug if this change was unintentional (?). To reproduce: - Run `xautolock -time 1 -locker xflock4` - Wait 5 minutes - Try to unlock - You will have to unlock several times or - Run `sleep 10 && xflock4` in a terminal - Run `xflock4` in another terminal - You will need to unlock twice
issue