A: 
  • SIGTERM is equivalent to "clicking the 'X' " in a window.
  • SIGTERM is what Linux uses first, when it is shutting down.
gbarry
+2  A: 

Typically you'd send SIGTERM, the default of kill. It's the default for a reason. Only if a program does not shutdown in a reasonable amount of time should you resort to SIGKILL.

As for SIGHUP, HUP stands for "hang up" and historically meant that the modem disconnected. It's essentially equivalent to SIGTERM. The reason that daemons sometimes use SIGHUP to restart or reload config is that daemons detach from any controlling terminals and therefore would never receive SIGTERM, so that signal was considered as "freed up" for general use. Not all daemons use this for reload! The default action for SIGHUP is to terminate and many daemons behave that way! So you can't go blindly sending HUPs to daemons and expecting them to survive.

Edit: SIGINT is probably inappropriate to terminate a process, as it's normally tied to ^C or whatever the terminal setting is to interrupt a program. Many programs capture this for their own purposes, so it's common enough for it not to work. SIGQUIT typically has the default of creating a core dump, and unless you want core files laying around it's not a good candidate, either.

Summary: if you send SIGTERM and the program doesn't die within your timeframe then send it SIGKILL.

dwc
A: 

HUP sounds like rubbish to me. I'd send it to get a daemon to re-read its configuration.

SIGTERM can be intercepted; your daemons just might have clean-up code to run when it receives that signal. You cannot do that for SIGKILL. Thus with SIGKILL you are not giving the daemon's author any options.

More on that on Wikipedia: http://en.wikipedia.org/wiki/Kill_(Unix)

innaM
A: 

SIGTERM actually means sending an application a message: "would you be so kind and commit suicide". It can be trapped and handled by application to run cleanup and shutdown code.

SIGKILL cannot be trapped by application. Application gets killed by OS without any chance for cleanup.

It's typical to send SIGTERM first, sleep some time, then send SIGKILL.

vartec
+7  A: 

SIGTERM tells an application to terminate. The other signals tell the application other things which are unrelated to shutdown but may sometimes have the same result. Don't use those. If you want an application to shut down, tell it to. Don't give it misleading signals.

Why so many seem to think more than one signal is necessary to convey that message is beyond me. If SIGTERM doesn't terminate it instantly, it's because the application has chosen to handle the signal. Which means it has a very good reason to not terminate immediately: It's got cleanup to do. If you don't allow it to finish that, there's no telling how it will behave the next time you start it or how much of its persistent data you've just corrupted.

For more information on what the real meaning of the signals is, see sigaction(2). And don't confuse "Default Action" with "Description", they are not the same thing.

IMO it's only typical for authors of bad scripts to send SIGKILL. And yes, bad scripts are everywhere.

Don't send SIGKILL. Ever. If the application handles the SIGTERM, it can take it a second to cleanup, it can take a minute, it can take an hour. Depending on what the application has to get done before it's ready to end. Any logic that "assumes" an application's cleanup sequence has taken long enough and needs to be shortcut or SIGKILLed after X seconds is just plain wrong.

The only reason why an application would need a SIGKILL to terminate, is if something was so horribly wrong that something bugged out during its cleanup sequence or so. In which case you can open a terminal and SIGKILL it manually. Aside from that, which you really should never ever encounter unless you're the one developing the application, the only one other reason why you'd SIGKILL something is because you want to prevent it from cleaning itself up; in which case you also don't want the SIGTERM first and after a timeout SIGKILL.

It's not because half the world uses SIGKILL after 5 seconds that it's not horribly wrong.

lhunath
You're right that there's a lot of misuse of SIGKILL out there. But there is a time and place to use it, even from a script. Many, many apps trap SIGTERM and exit gracefully in less than a second or within just a few seconds, and one of those is still running 30 secs later it's because it's wedged.
dwc
@dwc: Try letting it run once for an hour. If it doesn't die then it's "wedged" and either fix it, or be lazy and in the future SIGKILL it after some time. *Take note* that you're probably corrupting stuff and remember that this is NOT something you should be doing "by default".
lhunath
system PAUSE