Timeline for What if 'kill -9' does not work?
Current License: CC BY-SA 4.0
42 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 29, 2023 at 16:28 | review | Suggested edits | |||
| Jun 29, 2023 at 19:48 | |||||
| S Feb 7, 2023 at 20:02 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 4.0 | clarify that “ignoring intr” means that it's always on (for SIGKILL, which is the relevant aspect here) |
| S Feb 7, 2023 at 20:02 | history | suggested | Chandler 'AGI' | CC BY-SA 4.0 | noted that `intr` option has been deprecated and is ignored |
| Feb 7, 2023 at 19:53 | review | Suggested edits | |||
| S Feb 7, 2023 at 20:02 | |||||
| Sep 29, 2022 at 5:55 | comment | added | hafiz031 | I have a bash command running under os.system() in a python process. Killing the process doesn't seem to kill the bash command running under os.system() inside that python file. | |
| Sep 8, 2021 at 13:52 | comment | added | Gilles 'SO- stop being evil' | @Jean-MichaëlCelerier kill -9 is guaranteed to work unless there's a kernel or hardware bug. The usual reason to use it is when there's an application bug, and in that case it's guaranteed. | |
| Sep 8, 2021 at 13:46 | comment | added | Jean-Michaël Celerier | so kill -9 only works in the non-buggy case... but in general when you want to kill -9 something it's because there's a bug somewhere ... | |
| Sep 7, 2021 at 9:55 | comment | added | Gilles 'SO- stop being evil' | @Jean-MichaëlCelerier Either a kernel bug has corrupted memory, or a hardware failure has corrupted memory. | |
| Sep 7, 2021 at 9:02 | comment | added | Jean-Michaël Celerier | So why is my computer stuck before rebooting after "sending sigkill to process htop... Waiting for process: htop" (which was stuck before I tried to reboot) | |
| Apr 26, 2021 at 16:06 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 4.0 | added 643 characters in body |
| Jun 6, 2020 at 19:11 | comment | added | Gilles 'SO- stop being evil' | @HansDeragon If the filesystem is provided via FUSE, killing the process that provides the filesystem (not the process that's hung waiting for the filesystem) will unblock the system call. | |
| Jun 6, 2020 at 13:26 | comment | added | Hans Deragon | It is 2020, June, and under Ubuntu 19.10, I have a process (gVim) hanged on gvfs (webdav connection) for ever (timeout looks like ∞) in 'D' state. It is sad to see that even in this modern age, there is no mean to kill that process (and its associated X window on the screen) and the timeout is not well implemented. | |
| Mar 23, 2020 at 21:17 | comment | added | Eric | The idea is there (sort of) that a process being suspended while executing kernel code cannot be killed, but the devil is in the details. Where shall I start? | |
| Apr 30, 2019 at 15:05 | comment | added | rogerdpack | I had a process in the state of waiting for a system call, and eventually it exited, but it was in a Z, not D state...thanks for the tip! | |
| Jan 21, 2019 at 8:23 | comment | added | Gilles 'SO- stop being evil' | @DouglasGaskell See the last paragraph of my answer. A zombie process is already dead. If you can't open new instances, it isn't because of the zombie. It may be because the program died without deleting some lock file, or because of some completely different bug in the program. | |
| Jan 21, 2019 at 7:26 | comment | added | Douglas Gaskell | Kill -9 ALWAYS works Except when it doesn't. How do you kill a zombie process? I have a FM that's hung, and I can't open new instances of it, but I can't kill it either. In a case like this, what options do you have other than restarting? | |
| Dec 24, 2018 at 4:09 | comment | added | Bruno | @Gilles I agree "Killing a zombie doesn't make sense" --- but "what if zombie come to life" :-)))))) Happy Christmas | |
| Sep 23, 2018 at 18:57 | comment | added | Gilles 'SO- stop being evil' | @VectorVortec If it used CPU time, it wasn't a zombie. | |
| Sep 22, 2018 at 23:37 | comment | added | VectorVortec | @Gilles zombie processes can consume resources. I was in the python debugger and the python program started another process. I hit "ctrl" + 'c' which left a zombie that used 1/2 of a CPU. I owned it, but kill -9 didn't kill it, ever. Exiting the debugger killed it though. | |
| Jun 27, 2018 at 14:53 | comment | added | Ayberk Özgür | @Gilles I suspect the same. | |
| Jun 27, 2018 at 14:36 | comment | added | Gilles 'SO- stop being evil' | @AyberkÖzgür That's presumably a bug in a Bluetooth driver. | |
| Jun 27, 2018 at 12:47 | comment | added | Ayberk Özgür | We recently had a case where a daemon using the bluez API would stop responding to the KILL signal. | |
| Sep 14, 2017 at 20:24 | comment | added | Temak | The process can also be blocked if it was accessing sshfs | |
| Sep 8, 2017 at 17:13 | comment | added | Gilles 'SO- stop being evil' | @sudo Rebooting won't increase the likelyhood of messing something up. It isn't mathematically impossible, but the reboot wouldn't be the cause of the mess. If the reason for the effectively unkillable process is a buggy driver or hardware, then the buggy driver or hardware could cause a mess, but rebooting won't make it worse. | |
| Sep 8, 2017 at 0:24 | comment | added | sudo | Any chance that "killing the kernel" (rebooting?) during this blockage could permanently mess something up on the bootup disk or in a peripheral? | |
| Mar 18, 2017 at 7:24 | comment | added | nmz787 | as indicated here, the uninterruptable sleep may be triggered by unmounting/remounting/reconnecting the media/link: redhat.com/archives/rhl-list/2004-January/msg04543.html Unplugging a USB device (appearing as a serial port and mass-storage) fixed my issue of sublime-text hanging | |
| Dec 22, 2016 at 17:05 | comment | added | Shashank Vyas | @Tshepang .. lot of options here. If you know the port.. kill $(lsof -t -i:<port no>) Or else pkill .. or if nothing else works you should go ahead with killing tty :) | |
| Jun 15, 2016 at 11:03 | comment | added | Gilles 'SO- stop being evil' | @GreenRaccoon23 What worked wasn't sending the signal multiple times, sending it once would have had exactly the same effect. What worked was waiting long enough for the signal to be processed. | |
| Jun 15, 2016 at 4:35 | comment | added | GreenRaccoon23 | Something that worked for me is for i in $(seq 1 1000); do sudo kill -9 <pid>; done;. I just did it out of frustration but it actually worked. | |
| Mar 13, 2016 at 18:48 | comment | added | Gilles 'SO- stop being evil' | @jww There are process states where the process can't be killed, but the signal is queued up and can't be cancelled. As I explain, SIGKILL always works, but it doesn't always work immediately. | |
| Mar 13, 2016 at 6:20 | comment | added | user56041 | "kill -9 (SIGKILL) always works, provided you have the permission..." - I'm not sure that's correct. It depends on the process state in the kernel. There's a couple of states the process can be in such that it can't be killed. I wish I could find the post that discusses it.... | |
| Aug 10, 2013 at 2:06 | comment | added | nneonneo | @imz--IvanZakharyaschev: Heh, users of microkernels have known this convenience for a long time. Disk totally stuck? Kill and respawn disk server. NFS stuck? Kill and respawn nfs daemon. Since everything is a process, it is very hard to really hang a microkernel OS. | |
| Mar 30, 2013 at 12:34 | comment | added | imz -- Ivan Zakharyaschev | @Gilles Thanks, your advice (what to do with any FUSE fs) helped. I haven't been able to get rid of those hanging sshfs mounts for months, and some GUIs listing the filesystem tree were unusable simply because there were such mountpoints in my home directory (Thunar, "open file" and "save as" dialogs in most programs). Now I was able to simply kill the sshfs processes, and everything is fine again! So, in a sense, user-space FSs are superior to kernel-space FSs in the sense of the usability/convenience fo the system for the user! | |
| Mar 28, 2013 at 19:42 | comment | added | Gilles 'SO- stop being evil' | @imz--IvanZakharyaschev Not that I know of (but I might not know). With sshfs, as a last resort, you can kill the sshfs process (and likewise with any other FUSE filesystem: you can always force-unmount this way). | |
| Mar 28, 2013 at 14:55 | comment | added | imz -- Ivan Zakharyaschev | I had problems killing an ls process accessing an sshfs mount, when the remote server has beome unreachable. Is there a mount option for FUSE or sshfs, which I could use in future to avoid such situations? 2.6.30 kernel | |
| Aug 7, 2012 at 20:05 | comment | added | Martin Schröder | man 5 nfs: "The intr/nointr mount option is deprecated after kernel 2.6.25. Only SIGKILL can interrupt a pending NFS operation on these kernels, and if specified, this mount option is ignored to provide backwards compatibility with older kernels." | |
| Jan 11, 2011 at 21:39 | comment | added | jlliagre | I wrote too killing a zombie doesn't make sense but that doesn't prevent many people to try it and complain. Killing a process in interruptible sleep indeed works by design, but I was talking about killing a process in uninterruptible sleep which can fail if the system call never wake up. | |
| Jan 11, 2011 at 20:07 | comment | added | Gilles 'SO- stop being evil' | @jlliagre: Killing a zombie doesn't make sense, it's not alive to begin with. And killing a process in interruptible sleep does work, it's just (as with other signals) asynchronous. I've tried to clarify this in my edit. | |
| Jan 11, 2011 at 20:07 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 2.5 | mention init; clarify asynchronous delivery; mention zombies |
| Jan 11, 2011 at 12:27 | comment | added | jlliagre | Yor reply looks self contradicting. You start telling SIGKILL always works but end citing the uninterruptible sleep case, where SIGKILL might never work outside shutting down the kernel. There are also two cases where SIGKILL doesn't work. With zombies obviously as you can't kill already dead processes and with init, which by design is ignoring SIGKILL signals. | |
| Jan 11, 2011 at 10:52 | vote | accept | tshepang | ||
| Jan 10, 2011 at 20:08 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 2.5 |