Timeline for When should I not kill -9 a process?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 16, 2021 at 11:04 | comment | added | Hend | @dhruvbird so I guess when the process is killed files get closed? memory gets deallocated. file descriptor tables free, and any other system resources are back to the os? or not? and if the process causes zombies or orphans its only the pids that are stuck somewhere in a kernel structure, am I correct? | |
| Mar 20, 2018 at 16:14 | history | edited | Stéphane Chazelas | CC BY-SA 3.0 | added 71 characters in body |
| Jan 30, 2014 at 15:34 | comment | added | iconoclast | @dhruvbird: just because your DBs are supposed to come equipped with bullet-proof vests doesn't mean you should shoot them if you don't need to. While you may be right that it's not as risky as Arcege seems to say, I think his point still stands that it's risky and should be a last resort. | |
| Jan 29, 2014 at 0:30 | comment | added | dhruvbird | @Arcege The db file repair isn't a separate process, but a part of the startup routing when the process is restarted. Usually, you'd have daemontools or something such tool constantly monitoring your daemons. Additionally, repairing the file takes not much time since it's a journal replay, and not something expensive like an fsck. In fact, there's a discussion about this on HN (dbs are supposed to handle -9 and recover fact after that). | |
| Jan 28, 2014 at 20:36 | comment | added | Arcege | @dhruvbird But it would still be effort and possible downtime until the db file is repaired/restored (that's assuming that there are sufficient notifications to let you know of the corruption). Why deal with this risk by using something that should not be used? SIGKILL is not for terminating processes. | |
| Jan 28, 2014 at 20:18 | comment | added | dhruvbird | @Arcege I meant that all the databases (including sqlite) maintain separate journals and maintain the validity of these journals so that even if the db file is corrupted (say due to an incomplete read), the journal can be used to repair it. | |
| Jan 28, 2014 at 17:50 | comment | added | Jayson | (Disclaimer: Some of this may be Linux specific.) My progression is usually SIGINT (i.e. ctrl-C if there's a console), SIGQUIT (i.e. ctrl-\), SIGTERM, and only then SIGKILL. Note that some processes won't die, even with SIGKILL. If it's in a syscall that will never exit, it'll never receive that signal. Check top for a D status. Also, check dmesg. You may find that you've bumped a kernel bug and then all bets are off. The only time I go straight for SIGKILL is when the process has tons of memory in swap, then SIGKILL will free it without waiting to swap it all back in. | |
| Jan 28, 2014 at 15:36 | comment | added | Arcege | @dhruvbird With file descriptors opened with O_SYNC, then they would be safe with a SIGKILL. Anything else risks a file being closed before buffers are written to the file. Is the data corrupted beyond repair, possibly not, but you can't say, with SIGKILL, that it won't be corrupted. Behavior not withstanding, the risk is still there. To answer your question, SIGKILL is for extreme circumstances and corruption is an expected risk, so yes, anything that corrupts on SIGKILL is acceptable. | |
| Jan 28, 2014 at 9:34 | review | Suggested edits | |||
| Jan 28, 2014 at 10:21 | |||||
| S Jan 28, 2014 at 9:14 | history | edited | strugee | CC BY-SA 3.0 | `s/program/process` and clarified sentence structure. |
| S Jan 28, 2014 at 9:14 | history | suggested | Anko | CC BY-SA 3.0 | `s/program/process` and clarified sentence structure. |
| Jan 28, 2014 at 9:04 | review | Suggested edits | |||
| Jan 28, 2014 at 9:14 | |||||
| Jan 28, 2014 at 7:10 | comment | added | dmourati | killall -9 java ftw | |
| Jan 28, 2014 at 6:52 | comment | added | dhruvbird | @Arcege Do you think that using a database that corrupts data if killed with -9 is a database worth using after all? iirc, mysql, bdb, pg, etc... all behave well when killed with -9. | |
| Apr 3, 2011 at 11:10 | comment | added | penguin359 | @Mikel Another thing to through it, sometimes it's best to trick an app into cleaning itself up with a signal like SIGQUIT or SIGSEGV if it won't respond to SIGINT/SIGTERM. For example, a full screen 3-D app or even Xorg. Using SIGQUIT, it won't have a chance to clean-up anything, but tricking it into thinking a segment fault happen and it will feel it has no choice but to clean up and exit. | |
| Mar 10, 2011 at 11:36 | vote | accept | Mikel | ||
| Mar 9, 2011 at 12:39 | comment | added | Arcege | the compelling reason is that if you get in the habit of sending SIGKILL, then when you get to a program which will, for example, corrupt an important database for you or your company, you'll really regret it. kill -9 has its use, as a last-resort terminator, emphasis on last-resort; admins that use it before the last-resort a) do not understand being an admin too well, and b) shouldn't be on a production system. | |
| Mar 9, 2011 at 11:34 | comment | added | Mikel | Thanks. I agree. I guess I'm looking for a more compelling reason to not do it that is easy to convey to other sysadmins, and perhaps also some detailed recipes for debugging. | |
| Mar 9, 2011 at 10:26 | history | answered | geekosaur | CC BY-SA 2.5 |