How to release keyboard and mouse from grab by a hung unkillable app? [duplicate]












11
















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







share|improve this question













marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


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
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago
















11
















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







share|improve this question













marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


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
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago














11












11








11


4







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







share|improve this question















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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 days ago









RuslanRuslan

1,3071225




1,3071225




marked as duplicate by mosvy, Stephen Harris, roaima, Networker, Christopher yesterday


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 yesterday


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
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago



















  • A related question is unix.stackexchange.com/questions/494180 .

    – JdeBP
    2 days ago











  • also unix.stackexchange.com/questions/23164/…

    – mosvy
    2 days ago

















A related question is unix.stackexchange.com/questions/494180 .

– JdeBP
2 days ago





A related question is unix.stackexchange.com/questions/494180 .

– JdeBP
2 days ago













also unix.stackexchange.com/questions/23164/…

– mosvy
2 days ago





also unix.stackexchange.com/questions/23164/…

– mosvy
2 days ago










3 Answers
3






active

oldest

votes


















13














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.






share|improve this answer





















  • 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
    2 days ago











  • 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
    2 days ago



















2














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.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • 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
    2 days ago






  • 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
    2 days ago






  • 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
    2 days ago











  • 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
    2 days ago





















-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago




















3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









13














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.






share|improve this answer





















  • 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
    2 days ago











  • 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
    2 days ago
















13














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.






share|improve this answer





















  • 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
    2 days ago











  • 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
    2 days ago














13












13








13







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 days ago

























answered 2 days ago









RuslanRuslan

1,3071225




1,3071225








  • 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
    2 days ago











  • 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
    2 days ago














  • 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
    2 days ago











  • 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
    2 days ago








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
2 days ago





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
2 days ago













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
2 days ago





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
2 days ago













2














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.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • 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
    2 days ago






  • 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
    2 days ago






  • 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
    2 days ago











  • 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
    2 days ago


















2














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.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • 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
    2 days ago






  • 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
    2 days ago






  • 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
    2 days ago











  • 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
    2 days ago
















2












2








2







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.






share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










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.







share|improve this answer








New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 days ago









zdimensionzdimension

1293




1293




New contributor




zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






zdimension is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • 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
    2 days ago






  • 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
    2 days ago






  • 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
    2 days ago











  • 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
    2 days ago





















  • And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

    – Ruslan
    2 days ago













  • 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
    2 days ago






  • 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
    2 days ago






  • 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
    2 days ago











  • 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
    2 days ago



















And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

– Ruslan
2 days ago







And how do I re-attach keyboard back to the X server? Isn't this as useful as Ctrl+Alt+Backspace?

– Ruslan
2 days ago















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
2 days ago





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
2 days ago




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
2 days ago





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
2 days ago




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
2 days ago





@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
2 days ago













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
2 days ago







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
2 days ago













-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago


















-4














kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago
















-4












-4








-4







kill -9 often works when plain kill does not.






share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










kill -9 often works when plain kill does not.







share|improve this answer








New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 days ago









Jonathan DushoffJonathan Dushoff

1




1




New contributor




Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Jonathan Dushoff is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago
















  • 5





    See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

    – Ruslan
    2 days ago










5




5





See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

– Ruslan
2 days ago







See the OP: no signal will kill an app which is in Disk sleep. Besides, kill -9 is still kill(1).

– Ruslan
2 days ago





-

Popular posts from this blog

An IMO inspired problem

Image
14 4 This problem from IMO 1988 is said to be one of the most elegant ones in functional equations. Problem : The function $f$ is defined on the set of all positive integers as follows: begin{align} f(1) = 1, f(3) &= 3, f(2n) = f(n), \ f(4n+1) &= 2f(2n+1) - f(n), \ f(4n+3) &= 3 f(2n+1) - 2f(n) end{align} Find the number of $n$ with $f(n) = n, 1 leq n leq 1988$. The main idea towards the solution is realizing that these conditions stand for the fact that $f(n)$ just reverses the digits in the binary representation of the number $n$. So, essentially the solution is finding the number of binary pallindromes $leq 1988_{10}$. My question is the following : How to reformulate the problem so that $f(n)$ reverses the digits of $n$ in its ternary representation. Or even better, can we reformulate it for a
Read more

Management

Image
Management From Wikipedia, the free encyclopedia Jump to navigation Jump to search "Manager" redirects here. For other uses, see Management (disambiguation) and Manager (disambiguation). An organization chart for the United States Coast Guard shows the hierarchy of managerial roles in that organization. Business administration Management of a business Accounting Management accounting Financial accounting Financial audit Business entities Cooperative Corporation Limited liability company Partnership Sole proprietorship State-owned enterprise Corporate governance Annual general meeting Board of directors Supervisory board Advisory board Audit committee Corporate law Commercial law Constitutional documents Contract Corporate crime Corporate liability Insolvency law International trade law Mergers and acquisitions Economics Commodity Pu
Read more

Has there ever been an instance of an active nuclear power plant within or near a war zone?

Image
36 3 The question Has there ever been a military combat going on around an active (running or in outage but not decommissioned) commercial nuclear power plant? Or dangerously near it? If yes, how did the plant and its personnel fare in such situation? Why I ask Let's assume for the scope of this question modern commercial nuclear power plants (CANDU, PWR, BWR of generation II plus all of gen III and newer) are usually reasonably safe to operate given that the engineering has been done right and there is a whole cohort of very well trained personnel on-site at all times, well rested and with considerable resources on their hands. Things hard to get with an armed conflict like the recent Syrian war raging around. I can't seem to find any reference or a comprehensive article about this, hence this question.
Read more