
Why not kill -9 a process? - justinzollars
http://unix.stackexchange.com/questions/8916/why-not-kill-9-a-process
======
tptacek
Everything will probably be just fine if you kill-9 something. If a program
fails permanently and dramatically when it's kill-9'd, you should "remove it
from your filesystem", because it can't handle other, unavoidable abrupt
failures either.

~~~
chomp
I think that's rather harsh, MySQL/InnoDB can't handle kill -9. Granted,
kill-9'ing a database process is bad karma :)

~~~
protomyth
If a database cannot handle kill -9 then it cannot be considered transactional
and shouldn't be used.

~~~
scott_karana
Unless you're talking about filesystems with specific support for atomicity,
and databases with custom storage drivers for those filesystems, that's really
not fair.

It would be far too easy to kill any program mid-write().

~~~
zAy0LfpBZLC8mAC
That is what journaling is for. A database that corrupts data when you kill -9
it is garbage. A database has to survive without corruption when power fails
unexpectedly, and that's even harsher than kill -9 in terms of what can go
wrong if your code is sloppy.

------
randomdrake
I remember learning about kill as a kid, then kill -9 in college, and after
college re-learning it via Monzy[1].

I had sort of forgotten the importance of the signal argument. Such an
_incredibly powerful_ command that is nothing more than a representation of a
very simple decision or architecture [2]:

    
    
         Some of the more commonly used signals:
         1       HUP (hang up)
         2       INT (interrupt)
         3       QUIT (quit)
         6       ABRT (abort)
         9       KILL (non-catchable, non-ignorable kill)
         14      ALRM (alarm clock)
         15      TERM (software termination signal)
    

[1] -
[http://www.youtube.com/watch?v=Fow7iUaKrq4](http://www.youtube.com/watch?v=Fow7iUaKrq4)

[2] - man kill

~~~
ballard
kill -0 <pid> to test if a process is alive.

kill -9 -1 to send a KILL to every process.

~~~
dhimes
I went to kill -L and it didn't work! Linux Mint 15 (ubuntu saucy/debian
derivative)

~~~
warnhardcode
Heh I went to try it and sure enough it was in the manpage but didn't work on
the commandline because.....manpage was for /bin/kill but from the commandline
I was using the builtin kill. WOW!

    
    
      % kill -L
      kill: unknown signal: SIGV
      kill: type kill -l for a list of signals
    
      % which kill
      kill: shell built-in command
    
      % /bin/kill -L
       1 HUP      2 INT      3 QUIT     4 ILL      5 TRAP     6 ABRT     7 BUS
       8 FPE      9 KILL    10 USR1    11 SEGV    12 USR2    13 PIPE    14 ALRM
      15 TERM    16 STKFLT  17 CHLD    18 CONT    19 STOP    20 TSTP    21 TTIN
      22 TTOU    23 URG     24 XCPU    25 XFSZ    26 VTALRM  27 PROF    28 WINCH
      29 POLL    30 PWR     31 SYS

~~~
GrinningFool
Thanks for this, I didn't realize it.

You can disable kill (or any built-in)

Under zsh:

    
    
        disable kill 
    

Under bash:

    
    
        enable -n kill

------
colechristensen
Several of the answers on stackexchange and comments here are absurd.

SIGKILL shouldn't be your first resort but sometimes is necessary as a last
resort. If the sky falls and you can't deal with it, there's something wrong
in a lot of places which have nothing to do with signals.

~~~
ballard
Exactly. It should be the nuclear option of last resort.

~~~
colechristensen
But 'nuclear option' attaches too much meaning, if you're in the position,
you'll run into plenty of circumstances where SIGKILL is necessary. It's a
perfectly fine tool to use and deserves no extremist opinions.

~~~
mtdewcmu
Right... In Windows and OSX you have to do the same thing fairly often. It's
called "force quit" or something like that. Otherwise you'd sometimes be
waiting an eternity for programs to get themselves unstuck. If a program
leaves a messy state behind when you `kill -9` it, it will automatically clean
up the mess the next time it runs. If it doesn't, then don't bother using it,
because it's extremely poorly written. (If there are orphaned child processes
left behind, I kill them manually.)

Usually it's just an obviously good idea to send a milder signal first,
because it's less likely to leave orphaned child processes and `kill 345` is
just plain easier to type than `kill -9 345`. Also, trying a TERM signal first
gives you some feedback on how fubar the process really is.

~~~
Pxtl
Yeah, Windows has "Force Quit" baked into their regular shutdown process now -
if _any_ program is blocking the shutdown for more than a second or three, the
user will get the option to kill _everything_. Under windows, there is now no
excuse not to properly handle a forced abrupt termination, because the layman
users _will_ do it.

------
justin_vanw
Sometimes you have to kill -9, but you shouldn't do it unless you tried other
signals and they didn't work, and you know what the consequences are.

For example, postgresql forks a process for every connection. What you may not
know is, if you kill one of these processes, it needs to clean up it's use of
the shared memory pool. If you kill -9 _any_ of postgresql's child processes,
the other processes will see that a peer died uncleanly, and postgres will
just shut down rather than risk corruption.

Oh, the things we learn the hard way.

~~~
gaius
This is a Postgres thing tho', you can kill Oracle shadow processes willy-
nilly with no consequences. Oracle has another process PMON that will clear up
after them. If you kill PMON (or SMON) however the DB will shut down. However
no data will be lost; at one company I worked at kill -9 on SMON was the
normal way to shut the production DB down!

~~~
aidenn0
kill -9 on smon is used likely because I've seen "shutdown immediate" take
over an hour to complete...

------
kllrnohj
The Linux OOM killer (used heavily by Android as part of normal operation)
does a SIGKILL. I believe iOS does this as well.

So pretty sure this is totally fine and not a problem in the slightest, seeing
as some billion devices or so are doing this on a daily basis.

~~~
lazyant
I wouldn't say it's totally fine when oom kills mysqld and corrupts tables for
example when a shutdown as alternative would have been better. Unfortunately
oom-killer is not that smart.

~~~
jeltz
I really hope you are wrong about killing mysqld corrupting tables, because if
it does then I would not want mysql near my data. Databases should use a
journal for crash safety.

~~~
lazyant
Sometimes, not always but it does happen, I've seen it many times

------
nsxwolf
Sums it up nicely for me:

"I use kill -9 in much the same way that I throw kitchen implements in the
dishwasher: if a kitchen implement is ruined by the dishwasher then I don't
want it."

------
TeMPOraL
Somebody please write a bash script `murder' that sends 15, 2, 1 and then 9,
with slighth delay between each signal. I'd do it myself, but I'm not very
bash-proficient and have to run to work now ;).

~~~
ordinary
I've had a version of this for years. Your post made me take another look at
the code. I had to clean it up a little, but here it is:

[https://gist.github.com/anonymous/32b1e619bc9e7fbe0eaa](https://gist.github.com/anonymous/32b1e619bc9e7fbe0eaa)

(The cleanup might have introduces some subtle bugs, but a quick test showed
no issues. Let me know if you find some!)

~~~
TeMPOraL
Sweet, thanks!

    
    
        temporal@legion~/r/mintia> murder 4421                                       0 50/50℃  13:56:10 28.01.2014
        murder: Killed process with PID 4421 with signal TERM (15).
    

Works like charm :).

------
Dylan16807
So there are two answers, one saying to try without -9 first (which is
obvious), and the other suggesting you uninstall any program where -9 is
necessary.

Was this submitted to HN for more opinions? So people could see the
disagreeing answers? Something else?

~~~
eru
> [...] and the other suggesting you uninstall any program where -9 is
> necessary.

And vice versa, remove any program where -9 may cause damage.

------
jen_h
When you care enough to send the very best, kill -15. When you want evidence
(core dump), kill -11. For all other (most) purposes, kill -9 never hurt
anyone but a process you wanted shot down anyway.

------
MichaelBurge
I can give a real practical reason from experience - I was writing a script
that needed to pull data from the database. I noticed I was doing something
stupid in the SQL query, so I wanted to kill it and rerun it with the change.

I kill'd the script running it, and then kill -9'd it when that didn't work.
Two weeks later someone asked about my query that was still running on the
database.

And now I'm the one who warns people not to kill -9 scripts without
understanding why it's stuck and how to clean it up properly.

------
hcarvalhoalves
You will want to SIGKILL when you need to regain control, and/or when the
process is not fundamental. E.g. some ancillary script stuck at 100% CPU or
making the server swap crazy that isn't responding to SIGTERM. Anything more
fundamental is likely to respond well to SIGTERM or not have the CPU/swapping
problem in the first place.

------
coryfklein
If you're not a server admin, kill -9 probably won't mess up your own machine
in a significant way. I'm by no means a veteran, but I've used Linux as my
primary workstation for 4 years now and haven't yet had reason to regret using
kill -9. And given the number of times I have used it, I prefer a single kill
-9 as opposed to 2-3 more kills beforehand.

------
jeza
This just about sums it up: "Don't use kill -9. Don't bring out the combine
harvester just to tidy up the flower pot." (from this answer
[http://unix.stackexchange.com/a/8927](http://unix.stackexchange.com/a/8927))

------
ballard
Best to wait sufficiently if possible, because what's happening might just be
important to somebody.

If nothing else works, kill -9 -<master pid> to kill the whole process group,
otherwise detached processes owned by init could get messy.

~~~
dhimes
According to man 7 signal, killpg works for this

------
teddyh
See also “ _What to do when Ctrl + C can 't kill a process?_”
([https://superuser.com/questions/243460](https://superuser.com/questions/243460))

------
jdubs
kill = send a signal.

By far the easiest question to weed out inexperienced linux users.

~~~
ababab
Shouldn't that explanation be by followed by 'in order to request the
termination of the process'?

~~~
habosa
Not always. The kill system call can be used to send any signal, it's just got
a name that implies you're sending something like SIGKILL or SIGTERM. I have
written C programs that use kill for harmless inter-process communication.

~~~
eru
SIGUSER is quite common for that. Or SIGHUP.

~~~
brokenparser
By convention, SIGHUP is used by daemons to signal a change of configuration.

------
dschiptsov
There are two signals which cannot be intercepted and handled: SIGKILL and
SIGSTOP.

------
a3voices
Practically speaking, things almost never go wrong when you kill -9 a process,
as opposed to a more clean way. Also, time is money.

~~~
crimsonalucard
You must never use multiprocessing. If you're application spawns children
processes, kill -9 will leave all the children orphaned.

It is better for the parent to catch a TERM and relay that signal to all the
children. I find this to be a practical and typical use case...

~~~
zAy0LfpBZLC8mAC
If your application's child processes are orhpaned when the parent dies
unexpectedly (for more than a few milliseconds), that is a bug in your
program.

~~~
bnegreve
Not necessarily, processes spawned by bash don't necessarily have to die if
you kill bash. For example if you use disown/nohup .. etc.

~~~
zAy0LfpBZLC8mAC
That's not what is normally meant by "multiprocessing" \- multiprocessing is
when your application forks multiple processes of itself in order to get some
concurrency/parallelism, and those forked processes should monitor their
parent and exit immediately when the parent disappears.

~~~
bnegreve
True, but that's still a good reason to avoid SIGKILLing your processes.

