SIGTERM vs. SIGKILL

Sending signals to processes using kill on a Unix system is not a new topic for most systems administrators, but I’ve been asked many times about the difference between kill and kill -9.

Anytime you use kill on a process, you’re actually sending the process a signal (in almost all situations – I’ll get into that soon). Standard C applications have a header file that contains the steps that the process should follow if it receives a particular signal. You can get an entire list of the available signals on your system by checking the man page for kill.

Consider a command like this:

kill 2563

This would send a signal called SIGTERM to the process. Once the process receives the notice, a few different things can happen:

  • the process may stop immediately
  • the process may stop after a short delay after cleaning up resources
  • the process may keep running indefinitely

The application can determine what it wants to do once a SIGTERM is received. While most applications will clean up their resources and stop, some may not. An application may be configured to do something completely different when a SIGTERM is received. Also, if the application is in a bad state, such as waiting for disk I/O, it may not be able to act on the signal that was sent.

Most system administrators will usually resort to the more abrupt signal when an application doesn’t respond to a SIGTERM:

kill -9 2563

The -9 tells the kill command that you want to send signal #9, which is called SIGKILL. With a name like that, it’s obvious that this signal carries a little more weight.

Although SIGKILL is defined in the same signal header file as SIGTERM, it cannot be ignored by the process. In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight to the kernel init. At that point, init will stop the process. The process never gets the opportunity to catch the signal and act on it.

However, the kernel may not be able to successfully kill the process in some situations. If the process is waiting for network or disk I/O, the kernel won’t be able to stop it. Zombie processes and processes caught in an uninterruptible sleep cannot be stopped by the kernel, either. A reboot is required to clear those processes from the system.

Comments

  1. says

    Very good explanation, indeed!

    I was wondering, if I want to halt the machine at a given time, like shutdown -h 10:00, will shutdown
    send what signals? Will it kill the running programs DIsgracefully or not? Say I have transmission downloading an .iso, will it be killed/ended adequately?

  2. vilpan says

    Fernando,
    the usual behaviour is to send SIGTERM to all applications, wait for some time and send SIGKILL to applications that are still alive. The timeout between SIGTERM and SIGKILL might vary from system to system. So any running application is given time to TERMinate gracefully and it if it fails to do so within the timeout it will be KILLed.

  3. ramish says

    what happen if I send to proccesses kill -9 , i have heard that its destructing for memory for the whole system is it true ? ist there any risk of hramful behaviour ?
    thanks

  4. says

    ramish – If the process is in the middle of writing data to the disk when you issue the SIGKILL, it’s possible that data may be partially written and might corrupt any data files that application may be writing.

  5. ramish says

    Hello Major Hayden

    thanks 4 feedback, so this is only risk ? no other resouces which are involved are impacted ?
    Im mean memory or other processes in memory, ?

  6. notytony says

    Hi,

    I have got one doubt..when sigkill is sent to a process as you said the process will mostly be killed.But what happens if the process to be killed have some child threads.?Will those threads also be killed or will they be left as zombies?

    Thanks!

  7. Carol Bednar says

    I am debugging some code that has signal handlers declared for SIGTERM and SIGINT. however this process is being sent SIGKILL and i see the SIGTERM signal handler action. Does this mean said process is also receiving a SIGTERM somewhere along the line? SIGKILL implies no signal handling but immediate exit?
    thanks :-)

  8. says

    HONG –

    Yes. However, if one of the child processes is stuck waiting on something (like the disk, for example), sending a SIGKILL to the parent may only kill the parent process.

  9. says

    Hello aspiring sysadmins,

    DO NOT assume that SIGKILL is safe just because you haven’t lost data yet. Imagine force-quitting your text editor without ever having saved your work. Don’t do that :) Sure, your text editor might have an auto-save feature, but you absolutely can’t assume that every process is ok with getting shot in the head at any arbitrary time. Even in environments where SIGKILL is used aggressively, it is only safe to do so if you are *sure* that the process is clean. The only way to be sure of that is to have intimate knowledge of the process, or to have the process publish its clean / dirty state. One such implementation is Apple’s ‘sudden termination’, which allows the app to increment / decrement a reference counter around its data handling operations; this refcount is published to the process manager (launchd). If the app is clean, it can be safely sigkilled, otherwise it is send a SIGTERM. See the following:

    https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSProcessInfo_Class/Reference/Reference.html

    I’m not saying don’t ever use kill -9, I’ve done it myself a billion times. What I’m saying is, don’t assume it’s safe, i.e. check to see if you made a mess.

  10. THIRUPATHI PINNINTI says

    Hi all,
    I have a master and two child’s process in my application. I sent the SIGTERM to the master process and observed that Master got the SIGCHLD signal after some delay but i was excepting SIGHUP to any one of child. Can any one clarify this .. ?
    if I sent SIGKILL the application is killed immediately … !!

    Thanks in advance

  11. Muthukumaran says

    Thanks mate for this very useful blog. This is the first thing I’ve read this morning and, I feel, it already made my day. Been using Linux for first 2-3 years of my career but sill never knew it. Now I feel more wise :)

    Thanks again
    Muthukumaran M.

  12. Ganesh says

    Thanks, this is helpful info.

    The timeout between SIGTERM and SIGKILL might vary from system to system, I am on Ubuntu 12.04, where can check this timeout value? Can we increase this?

  13. naxa says

    > In fact, the process isn’t even made aware of the SIGKILL signal since the signal goes straight to the kernel init.

    you mean SIGTERM?

  14. Aswin says

    Hi,

    I have process which has multiple threads.

    The state of the process is SLl+

    (from man ps)
    S = interruptable sleep
    L = has pages locked into memory
    1 = ?
    + = is in the foreground process group.

    At this stage if i send signals(SIGINT, SIGTERM or SIGKILL);

    the whole system hangs.

    Could you please tell me, what causes this hang.

    Thank you
    Ashwin

Trackbacks

Leave a Reply

Your email address will not be published. Required fields are marked *