When should I not kill -9 a process?
unix.stackexchange.com
When should I not kill -9 a process?
1–10 of 85 posts
Re: When should I not kill -9 a process?
#2Fiber optic cables are dug up by backhoes. Hard drives randomly fail. RAM is corrupted by cosmic rays. Racks lose power. CPU fans stop spinning.
If your process relies on not being kill -9'd, then you might as well quit programming and go buy a lottery ticket.
Re: When should I not kill -9 a process?
#3Well, there is always this scenario: when you can't even use CTRL+ALT+F2 to get to some type of terminal and only the power button, held in for ten seconds, will do. That's when you should not 'kill -9'.
I have heard the best practice advice for many years and I think that the 'you should send some friendly signal first' is not universally what works out best. For instance, if your Chrome browser is getting out of hand and the system is permanently doing some 96% wait for some reason, a gentle killing of Chrome will take ages and, when it restarts, you might get some but not all of your tabs back. With a killall -s 9 you can be back to work quickly with all your tabs (and underlying swappiness problem hopefully resolved).
Re: When should I not kill -9 a process?
#4As if often the case with stackoverflow answers, all of them are wrong in different ways. You should only kill -9 when every other signal the program is likely to respond to has not worked. kill -9 is likely to leave program in a state that requires manual intervention, especially if that program is a database.
If you're a developer, before you kill -9 a program send SIGTERM (ie kill without args or kill -15). If the program does not respond, run gdb -p and then "thread apply all bt" before killing it. At the very least, you should get a good idea of why it was not responding to other signals.
Re: When should I not kill -9 a process?
#5Fiber optic cables are dug up by backhoes. Hard drives randomly fail. RAM is corrupted by cosmic rays. Racks lose power. CPU fans stop spinning. If your process relies on not being kill -9'd, then you might as well quit programming and go buy a lottery ticket.
Right: programmers shouldn't rely on it, but neither should it be the only tool that users reach for when they want something to stop.
Re: When should I not kill -9 a process?
#6My naive answer: If a normal `kill` did not do the trick.
At least that what I do.
I guess a process is given more space to "clean up after itself" with a normal `kill`; where a `kill -9` forces it to die.
Anyway; I don't know the exact answer -- will come back later to read a wiser person's answer. :)
Re: When should I not kill -9 a process?
#7Over 15 years ago, as a teenager, I taught Linux / UNIX Admin courses, and worked as a consultant advising folks, and in the late 90s I was very adamant that you should never -9 anything unless you know exactly what you are doing.
As infrastructures have grown, and I have managed large applications involving tens to hundreds, often over a thousand servers, and I have grown to accept that a power supply can fail and a node can disappear from the network and it's even possible that none of its' components, including its' drives, will ever work again. I've never _really_ experienced such a catastrophic failure, but it's a lot easier to sleep at night if you just assume that.
kill -9 should never be worse than pulling the power plug, which is what netflix's chaos monkey always tries to simulate.
we all have to live on a continuum of how much of that we can survive, but if you always assume abrubt failure, it'll be pretty tough to give you a bad day.
Re: When should I not kill -9 a process?
#8Fiber optic cables are dug up by backhoes. Hard drives randomly fail. RAM is corrupted by cosmic rays. Racks lose power. CPU fans stop spinning. If your process relies on not being kill -9'd, then you might as well quit programming and go buy a lottery ticket.
This is a bit like saying that since your car can do emergency braking, you should always do emergency braking. Some processes clean up after themselves more neatly, or finish the current run of what they're doing first. It's dependent on what it is that you're stopping.
Re: When should I not kill -9 a process?
#9Over 15 years ago, as a teenager, I taught Linux / UNIX Admin courses, and worked as a consultant advising folks, and in the late 90s I was very adamant that you should never -9 anything unless you know exactly what you are doing. As infrastructures have grown, and I have managed large applications involving tens to hundreds, often over a thousand servers, and I have grown to accept that a power supply can fail and a…
To follow this up: test these situations, design yourself into resilience. obviously, you can't build perfection in a day, but for anything you rely on, be it mysql, redis, memcached, postgresql, rabbitmq, whatever, just kill -9 that shit in staging periodically while a few people hit the url, and see what happens, what logs, etc.. assume failure.
Re: When should I not kill -9 a process?
#10As if often the case with stackoverflow answers, all of them are wrong in different ways. You should only kill -9 when every other signal the program is likely to respond to has not worked. kill -9 is likely to leave program in a state that requires manual intervention, especially if that program is a database. If you're a developer, before you kill -9 a program send SIGTERM (ie kill without args or kill -15). If the…
You can't really corrupt a database that easily, can you? That's half the point of using a database, so you have transactions, etc.