How to release keyboard and mouse from grab by a hung unkillable app? [duplicate]
This question already has an answer here:
Command for forcing a pointer ungrab (captured mouse release)
3 answers
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?
x11 keyboard
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher Jan 14 at 19:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
Command for forcing a pointer ungrab (captured mouse release)
3 answers
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?
x11 keyboard
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher Jan 14 at 19:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20
add a comment |
This question already has an answer here:
Command for forcing a pointer ungrab (captured mouse release)
3 answers
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?
x11 keyboard
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
This question already has an answer here:
Command for forcing a pointer ungrab (captured mouse release)
3 answers
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?
This question already has an answer here:
Command for forcing a pointer ungrab (captured mouse release)
3 answers
x11 keyboard
x11 keyboard
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
asked Jan 13 at 9:40
RuslanRuslan
1,3071225
1,3071225
marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher Jan 14 at 19:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher Jan 14 at 19:44
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20
add a comment |
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20
add a comment |
3 Answers
3
active
oldest
votes
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.
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
2
One caveat to notice is thatxkillon 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 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.
– mosvy
Jan 13 at 19:23
add a comment |
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.
answered Jan 13 at 15:34
zdimensionzdimension
1293
And how do I re-attach keyboard back to the X server? Isn't this as useful asCtrl+Alt+Backspace?
– Ruslan
Jan 13 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 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 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 ofSysRq+Ris really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
– kasperd
Jan 13 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 at 17:05
add a comment |
kill -9 often works when plain kill does not.
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,kill -9is still kill(1).
– Ruslan
Jan 13 at 18:56
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
2
One caveat to notice is thatxkillon 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 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.
– mosvy
Jan 13 at 19:23
add a comment |
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.
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
2
One caveat to notice is thatxkillon 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 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.
– mosvy
Jan 13 at 19:23
add a comment |
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.
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
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.
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
edited Jan 13 at 19:18
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
answered Jan 13 at 9:40
RuslanRuslan
1,3071225
1,3071225
2
One caveat to notice is thatxkillon 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 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.
– mosvy
Jan 13 at 19:23
add a comment |
2
One caveat to notice is thatxkillon 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 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.
– mosvy
Jan 13 at 19:23
2
2
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 at 17:01
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 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.
– mosvy
Jan 13 at 19:23
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.
– mosvy
Jan 13 at 19:23
add a comment |
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.
answered Jan 13 at 15:34
zdimensionzdimension
1293
And how do I re-attach keyboard back to the X server? Isn't this as useful asCtrl+Alt+Backspace?
– Ruslan
Jan 13 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 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 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 ofSysRq+Ris really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
– kasperd
Jan 13 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 at 17:05
add a comment |
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.
answered Jan 13 at 15:34
zdimensionzdimension
1293
And how do I re-attach keyboard back to the X server? Isn't this as useful asCtrl+Alt+Backspace?
– Ruslan
Jan 13 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 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 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 ofSysRq+Ris really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
– kasperd
Jan 13 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 at 17:05
add a comment |
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.
answered Jan 13 at 15:34
zdimensionzdimension
1293
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.
answered Jan 13 at 15:34
zdimensionzdimension
1293
answered Jan 13 at 15:34
zdimensionzdimension
1293
answered Jan 13 at 15:34
zdimensionzdimension
1293
answered Jan 13 at 15:34
zdimensionzdimension
1293
1293
And how do I re-attach keyboard back to the X server? Isn't this as useful asCtrl+Alt+Backspace?
– Ruslan
Jan 13 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 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 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 ofSysRq+Ris really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
– kasperd
Jan 13 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 at 17:05
add a comment |
And how do I re-attach keyboard back to the X server? Isn't this as useful asCtrl+Alt+Backspace?
– Ruslan
Jan 13 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 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 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 ofSysRq+Ris really only useful if you cannot use a remote terminal (for example if networking or sshd is down).
– kasperd
Jan 13 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 at 17:05
And how do I re-attach keyboard back to the X server? Isn't this as useful as
Ctrl+Alt+Backspace?– Ruslan
Jan 13 at 16:44
And how do I re-attach keyboard back to the X server? Isn't this as useful as
Ctrl+Alt+Backspace?– Ruslan
Jan 13 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 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 at 16:44
2
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 at 16:46
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 at 16:46
2
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 at 17:00
@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 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 at 17:05
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 at 17:05
add a comment |
kill -9 often works when plain kill does not.
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,kill -9is still kill(1).
– Ruslan
Jan 13 at 18:56
add a comment |
kill -9 often works when plain kill does not.
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,kill -9is still kill(1).
– Ruslan
Jan 13 at 18:56
add a comment |
kill -9 often works when plain kill does not.
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
kill -9 often works when plain kill does not.
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
answered Jan 13 at 17:49
Jonathan DushoffJonathan Dushoff
1
1
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,kill -9is still kill(1).
– Ruslan
Jan 13 at 18:56
add a comment |
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,kill -9is still kill(1).
– Ruslan
Jan 13 at 18:56
5
5
See the OP: no signal will kill an app which is in Disk sleep. Besides,
kill -9 is still kill(1).– Ruslan
Jan 13 at 18:56
See the OP: no signal will kill an app which is in Disk sleep. Besides,
kill -9 is still kill(1).– Ruslan
Jan 13 at 18:56
add a comment |
A related question is unix.stackexchange.com/questions/494180 .
– JdeBP
Jan 13 at 12:18
also unix.stackexchange.com/questions/23164/…
– mosvy
Jan 13 at 19:20