Unresponsive keyboard after reload

[snoitallicso]

Every time as I reboot sxhkd, I pray to God that the keyboard continues to work. The thing is, when I press super + esc, it can make keyboard become unresponsive. It's a roulette - only 20% of the time I catch this case and haven't yet figured out when it occurs.

No key combinations help bring the keyboard to life, plug/unplug from usb doesn't help, the mouse keeps working like everything else in the system but not keyboard. I end up having to reboot the computer via hardware reset.

This problem is at least four years old: https://www.reddit.com/r/bspwm/comments/93bhr6/my_keyboard_become_unresponding_after_reload_sxhkd/

Add a configuration check for an errors like it does i3wm?

[shao113]

I struggled with a similar issue where reloading the configuration would randomly crash sxhkd, though I can't remember if it would take the keyboard out with it.

I ended up modifying the signal-handling code, which I've been running crash-free for two years now. It's here if you want to give it a shot: https://github.com/shao113/sxhkd

[Minda1975]

Same problem here. If I press shortcut super + Escape, I can't type anything at all. I have to switch to another console (by Ctrl+Alt+F2) and kill bspwm pkill bspwm. I am using Arch linux and the shxkd configuration is unchanged (default config).

P.S.

I found a simple solution. Instead of the standard command pkill -USR1 -x sxhkd, i use the simple command pkill sxhkd && sxhkd. Works well.

[christoph-blessing]

I have the same problem. Reloading works fine most of the time but sometimes the keyboard just stops working completely. Then I have to reset the whole system to get it working again.

edit: Thanks to @Minda1975 I am now using pkill -x sxhkd && sxhkd and that seems to alleviate the issue. Altough I can still break it by rapidly pressing the keybind.

[ByteDrummer]

pkill sxhkd && sxhkd doesn't seem to work for me. Either way, if I hold down the key for too long, my keyboard becomes unresponsive. The problem seems to be that sxhkd spams the hotkey that you press without long enough intervals. I changed the keybind to super + alt + Escape so that I don't accidentally press it instead of super + Tab.

[your-friend-alice]

@shao113 can you make a pull request? It would be nice for your fix to make it upstream and eventually end up in distro packages, and the patch looks pretty tidy so I can't imagine it being rejected.

In the meantime, for anyone who wants to keep using the version packaged with their distro, this workaround appears to work:

super + Escape
	sleep 0.5
	pkill -USR1 -x sxhkd

(obviously the first line will differ based on your reload key combination)

adding a small sleep before the pkill prevents it from happening too fast. In my very basic tests (mashing super + Escape and other shortcuts, holding down super + escape for longer than the keyboard repeat delay) I was able to reliably trigger this bug, and after adding the sleep I was no longer able to. note that the order is important; the sleep must come before the pkill.

This is just replacing one race condition with a more improbable race condition though, so ideally @shao113's patch makes it upstream soon

[shao113]

Since my previous message, I've had this issue crop up a few times with my patch as well. It's much more rare to occur, but for some, it may arguably be worse since it leaves the process hanging instead of crashing - breaking any auto-restart mechanisms they may rely on.

[your-friend-alice]

for what it's worth, my stock sxhkd (0.6.2 from the debian repo) 's failure mode is also hanging, so i don't think your fix makes it worse. but i def understand not wanting to submit an incomplete fix

[shao113]

Oh, that's interesting; stock sxhkd would often crash for me during the brief window signals are unhandled, so I guess the hung-keyboard is a separate issue.

Edit: I think this is due to events left pending while the fd was already read elsewhere, leaving pselect() stuck waiting for new presses that can't be produced; polling for these stray events beforehand seems to alleviate it.