19

Suppose I have an X application, which grabs keyboard and mouse as its normal mode of operation (e.g. QEMU), but which, due to a bug somewhere, hangs really hard (e.g. gets stuck in Disk sleep). Normally I'd kill an app using kill(1) from a remote terminal, but if the app is in Disk sleep mode, it can't really be killed. I could kill this app's connection to X server by the xkill utility, but this time I can't do this because mouse is grabbed, so xkill will fail to run.

So, how do I release my keyboard and mouse from grab by an X client, if I'm willing to sacrifice this client, but am unable to kill it by the OS means?

1

3 Answers 3

Reset to default
18

Although the most well-known use mode of xkill is "click to kill", there's an option -id, which can be supplied with Window Id of the client you want to disconnect from X server. Then, if you can access your X session from a remote terminal/VT, you can use xprop or some other means to get the Id, and pass it to xkill.

Suppose that current active window belongs to the X client who grabbed the keys&mouse. Then the following will kill this client's connection to the X server and thus release keyboard and mouse from the grab:

winid=$(xprop -root _NET_ACTIVE_WINDOW | cut -d# -f2)
xkill -id $winid

This actually worked for me when I tried to get rid of QEMU's grab when QEMU was stuck in Disk sleep.

2
  • 3
    One caveat to notice is that xkill on a hung window is not guaranteed to kill the process. It's quite possible for a process to be stuck so badly it won't notice that its window is gone. Still sometimes it's useful enough to get rid of the window first and deal with the process later.
    – kasperd
    Jan 13, 2019 at 17:01
  • of course the process won't notice anything if it's in an uninterruptible sleep; if it ever wakes up, it may die with an X11 error; that's why it's much better to force release its grabs (as in the linked q&a's) than cutting short its connection to the X11 server with xkill/XKillClient.
    – user313992
    Jan 13, 2019 at 19:23
3

You could try the standard SysRq+R trick which should release the keyboard from the X server, or the Ctrl+Alt+1-6 combination that changes the current console, maybe allowing you to run a terminal and kill the faulty program.

5
  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?
    – Ruslan
    Jan 13, 2019 at 16:44
  • I don't know how you could re-attach it to X, but it would at least allow you to kill the process that's locking the input
    – zdimension
    Jan 13, 2019 at 16:44
  • 2
    Wait, you imply killing it via kill(1) or similar. This doesn't work, as described in the OP. And anyway, simply killing the process (even if it worked) isn't enough: the aim is to re-gain control via keyboard, while this answer removes this control from the whole X server instead.
    – Ruslan
    Jan 13, 2019 at 16:46
  • 2
    @Ruslan I think the keyboard should re-attach if you switch to another VT and back to the X server. But as you pointed out, it doesn't help if you cannot kill the process. The use of SysRq + R is really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
    – kasperd
    Jan 13, 2019 at 17:00
  • OK, re-attachment happens automatically when I switch back to X server's VT — just checked. Still, using the OS means of killing the process makes this not-an-answer.
    – Ruslan
    Jan 13, 2019 at 17:05
-5

kill -9 often works when plain kill does not.

1
  • 6
    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).
    – Ruslan
    Jan 13, 2019 at 18:56

Not the answer you're looking for? Browse other questions tagged .