handle shell surface becoming unresponsive

[acrisci]

What should we do if a shell surface becomes unresponsive?

In i3, it will just stay on the screen forever. You have to kill the pid or use something like xkill.

We could ping the surface and do something when it times out, like gray out the surface. Maybe a command would be appropriate like kill --force to forcefully disconnect a client in this case.

[Kommynct]

Is this still an issue or is there a workaround now?

Sorry to bump I just can't imagine there isn't a better solution by now

[ewtoombs]

I agree, sway needs this pretty badly. An alacritty terminal has gone unresponsive and I can't figure out which one it is just by looking at ps -ef. I need to close all 10 or so of my terminals just to figure out which one it is, so I can kill it.

[kuon]

I'm in favor of the following behavior:

• kill tries to close the window, if the process inside is unresponsive, it grays the window (after like 500ms)
• kill --force is added and can be bound to a keybind, to explicitly kill frozen window with kill -9
• maybe add a configuration timeout to automatically kill -9 frozen window, but I am not really in favor of that, because kill -9 might not be desired in some case, like waiting to save on a network drive, I think the manual way is enough

[jgarvin]

I have this in my sway config (note that this differs from the default bindings, you may need to change the keys):

    bindsym $mod+q kill
    bindsym $mod+Shift+q exec ~/etc/swaykill.sh # REALLY kill it

And then swaykill.sh contains:

#!/usr/bin/env bash

kill -9 $(swaymsg -t get_tree | jq '.. | select(.type?) | select(.focused==true) | .pid')

Then pressing Win+Shift+Q sends SIGKILL to the currently focused window. It would be nice if there were a default for something like this though.