11 ms·
Why not kill -9 a process?
- Dylan16807 13y agoSo 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 13y ago> [...] and the other suggesting you uninstall any program where -9 is necessary. And vice versa, remove any program where -9 may cause damage.
- randomdrake 13y agoI 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
- deleted 13y ago[deleted]
- ballard 13y agokill -0 <pid> to test if a process is alive. kill -9 -1 to send a KILL to every process.
- dhimes 13y agoI went to kill -L and it didn't work! Linux Mint 15 (ubuntu saucy/debian derivative)
- warnhardcode 13y agoHeh 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 13y agoThanks for this, I didn't realize it. You can disable kill (or any built-in) Under zsh: disable kill Under bash: enable -n kill
- deleted 13y ago[deleted]
- dhimes 13y agoAgree with grinningfool- thank you! EDIT- at least it looks like the calls are the same.
- yiedyie 13y agoYou're right, nobody mentioned if the process is <defunct>: http://unix.stackexchange.com/a/111316/22558 http://unix.stackexchange.com/a/111316/22558
- toyg 13y agoI wonder if there is space to do with *nix signals what REST did with HTTP verbs.
- vincentkriek 13y agoMonzy should keep making music. I want new tracks!
- tptacek 13y agoEverything 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.
- agwa 13y ago> 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. There is a lot of middle ground between failing "permanently and dramatically" and shutting down cleanly. What about a program that can recover after an abrupt termination, but only after a time-consuming recovery from a journal? What about a program that can recover after an abrupt termination, but only after you manually remove a lock file? These are cases where it's not "just fine" to use SIGKILL, but not so bad as to warrant removing the program. Generally your life will be easier if you don't take the sledgehammer approach to killing processes, and at least try a non-SIGKILL first.
- dwc 13y agoYour reply is the real answer to the linked question. SIGTERM serves a real purpose, and almost always it works to end the process cleanly and promptly. If a process doesn't respond reasonably to SIGTERM, then you should consider removing it from your filesystem.
- FooBarWidget 13y agoUnfortunately the signals are badly named. Last time I explained to someone the difference between SIGTERM and SIGKILL. He was baffled. He: You mean SIGKILL isn't the signal for graceful termination? And it isn't sent by default when invoking `kill <PID>`? Me: Nope. Why do you think that? He: Well, the command is called `kill`. Me: ...good point.
- majelix 13y ago
- jdubs 13y agokill = send a signal. By far the easiest question to weed out inexperienced linux users.
- ababab 13y agoShouldn't that explanation be by followed by 'in order to request the termination of the process'?
- beedogs 13y agoNot necessarily. You can send the CONTinue signal to a process using the kill command. This will not cause the process to terminate.
- twinge 13y agoOr use "kill -0 <pid>" to check if a signal can be sent/the pid exists.
- rahimnathwani 13y agoOr use kill -USR1 <pid> to check the progress of dd
- DHowett 13y agoOnly if you've enabled it. If you've not, the process will terminate unceremoniously (in a mechanism borne entirely out of hatred for users.) This is my favourite part of dd: The "will I receive a status report or will I terminate my long-running copy?" gamble.
- jsight 13y agoIs that a BSD thing? I've never had to enable it on Linux to avoid killing the process.
- a3voices 13y agoPractically speaking, things almost never go wrong when you kill -9 a process, as opposed to a more clean way. Also, time is money.
- crimsonalucard 13y agoYou 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 13y agoIf 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 13y agoNot necessarily, processes spawned by bash don't necessarily have to die if you kill bash. For example if you use disown/nohup .. etc.
- zAy0LfpBZLC8mAC 13y agoThat'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 13y agoTrue, but that's still a good reason to avoid SIGKILLing your processes.
- kllrnohj 13y agoThe 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.
- gilgoomesh 13y agoiOS may use SIGKILL when out of memory or you're killed in the background (in most cases it sends a memory warning or -[NSApplication applicationWillTerminate:] message first and gives up to 5 seconds before SIGKILL). You do need to be a little careful as an app writer. All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ.
- kllrnohj 13y ago> All your file writes should be atomic (either SQLite/CoreData or using the atomic write methods in CoreFoundation and Objective-C) or you must be able to detect and delete partially files and recover in-situ. You should be doing that regardless, there's nothing special about SIGKILL in this regard. Dirty pages will still get flushed to disk, so SIGKILL is safer than, say, sudden power loss. Which isn't exactly unheard of on battery powered devices, after all.
- tjohns 13y agoAndroid's OOM killer won't run until after an activity's onPause() or onStop() method has been called, which gives applications a chance to save their state. A foreground activity is typically considered unkillable. Background services have weaker lifecycle guarantees, but the system can be asked to automatically restart your service and re-delivery any Intents that were being processed. It's not like the system is regularly killing apps without any recovery options. Dealing with these lifecycle events is a key part of Android development, so apps are designed to deal with them. See: http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle http://developer.android.com/reference/android/app/Activity.... http://developer.android.com/reference/android/app/Service.html#ProcessLifecycle http://developer.android.com/reference/android/app/Service.h...
- jen_h 13y agoWhen 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.
- justin_vanw 13y agoSometimes 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.
- dscrd 13y agoSome databases allow local shared memory connections. So, if you kill -9 a regular client that connects to the database that way, the whole database goes down. Fun times!
- gaius 13y agoThis 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 13y agokill -9 on smon is used likely because I've seen "shutdown immediate" take over an hour to complete...
- jeza 13y agoThis 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)
- hcarvalhoalves 13y agoYou 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.
- colechristensen 13y agoSeveral 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 13y agoExactly. It should be the nuclear option of last resort.
- colechristensen 13y agoBut '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 13y agoRight... 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 13y agoYeah, 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.
- ballard 13y agoBest 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 13y agoAccording to man 7 signal, killpg works for this
- TeMPOraL 13y agoSomebody 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 13y agoI'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 13y agoSweet, 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 :).
- teddyh 13y agoSee also “What to do when Ctrl + C can't kill a process?” (https://superuser.com/questions/243460 https://superuser.com/questions/243460)
- dschiptsov 13y agoThere are two signals which cannot be intercepted and handled: SIGKILL and SIGSTOP.
- nsxwolf 13y agoSums 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."
- coryfklein 13y agoIf 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.
- MichaelBurge 13y agoI 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.