How does SIGINT relate to the other termination signals such as SIGTERM, SIGQUIT and SIGKILL?
SIGTERM
and SIGKILL
are intended for general purpose "terminate this process" requests. SIGTERM
(by default) and SIGKILL
(always) will cause process termination. SIGTERM
may be caught by the process (e.g. so that it can do its own cleanup if it wants to), or even ignored completely; but SIGKILL
cannot be caught or ignored.
SIGINT
and SIGQUIT
are intended specifically for requests from the terminal: particular input characters can be assigned to generate these signals (depending on the terminal control settings). The default action for SIGINT
is the same sort of process termination as the default action for SIGTERM
and the unchangeable action for SIGKILL
; the default action for SIGQUIT
is also process termination, but additional implementation-defined actions may occur, such as the generation of a core dump. Either can be caught or ignored by the process if required.
SIGHUP
, as you say, is intended to indicate that the terminal connection has been lost, rather than to be a termination signal as such. But, again, the default action for SIGHUP
(if the process does not catch or ignore it) is to terminate the process in the same way as SIGTERM
etc. .
There is a table in the POSIX definitions for signal.h
which lists the various signals and their default actions and purposes, and the General Terminal Interface chapter includes a lot more detail on the terminal-related signals.
kill -INT vs kill -TERM
The only difference in the response is up to the developer. If the developer wants the application to respond to SIGTERM
differently than to SIGINT
, then different handlers will be registered. If you want to stop a background process gracefully, you would typically send SIGTERM
. If you are developing an application, you should respond to SIGTERM
by exiting gracefully. SIGINT
is often handled the same way, but not always. For example, it is often convenient to respond to SIGINT
by reporting status or partial computation. This makes it easy for the user running the application on a terminal to get partial results, but slightly more difficult to terminate the program since it generally requires the user to open another shell and send a SIGTERM
via kill
. In other words, it depends on the application but the convention is to respond to SIGTERM
by shutting down gracefully, the default action for both signals is termination, and most applications respond to SIGINT
by stopping gracefully.
Why does POSIX demand that system(3) ignores SIGINT and SIGQUIT?
SIGINT
and SIGQUIT
are terminal generated signals. By default, they're sent to the foreground process group when you press Ctrl+C
or Ctrl+\
respectively.
I believe the idea for ignoring them while running a child via system
is that the terminal should be as if it was temporarily owned by the child and Ctrl+C
or Ctrl+\
should temporarily only affect the child and its descendants, not the parent.
SIGCHLD
is blocked so that system
's the SIGCHLD
caused by the child terminating won't trigger a SIGCHLD
handler if you have one, because such a SIGCHLD
handler might reap the child started by system
before system
reaps it.
SIGTERM and SIGKILL
I think they must have meant this:
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 SIGHUP, so that signal was considered as "freed up" for general use.
That is, SIGHUP is a signal that would normally be sent only to a process that has a controlling terminal. Since daemons don't have a controlling terminal, they wouldn't get a SIGHUP for the normal reason. So they redefine it for another purpose.
But I could be misinterpreting the original author of that sentence. I think you did the right thing by asking for clarification in a comment on the original answer. Posting here as a separate question doesn't seem ideal...
In what order should I send signals to gracefully shutdown processes?
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.
Some people believe the smart standard way of terminating a process is by sending it a slew of signals, such as HUP, INT, TERM and finally KILL. This is ridiculous. The right signal for termination is SIGTERM and if SIGTERM doesn't terminate the process instantly, as you might prefer, 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 work to do. If you interrupt that cleanup work with other signals, there's no telling what data from memory it hasn't yet saved to disk, what client applications are left hanging or whether you're interrupting it "mid-sentence" which is effectively data corruption.
For more information on what the real meaning of the signals is, see sigaction(2). Don't confuse "Default Action" with "Description", they are not the same thing.
SIGINT
is used to signal an interactive "keyboard interrupt" of the process. Some programs may handle the situation in a special way for the purpose of terminal users.
SIGHUP
is used to signal that the terminal has disappeared and is no longer looking at the process. That is all. Some processes choose to shut down in response, generally because their operation makes no sense without a terminal, some choose to do other things such as recheck configuration files.
SIGKILL
is used to forcefully remove the process from the kernel. It is special in the sense that it's not actually a signal to the process but rather gets interpreted by the kernel directly.
Don't send SIGKILL. - SIGKILL
should certainly never be sent by scripts. 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 bugged out during its cleanup sequence. In which case you can open a terminal and SIGKILL
it manually. Aside from that, the only one other reason why you'd SIGKILL
something is because you WANT to prevent it from cleaning itself up.
Even though half the world blindly sends SIGKILL
after 5 seconds it's still horribly wrong thing to do.
Related Topics
How to Find All Files Containing Specific Text on Linux
How to Write a Bash Script to Restart a Process If It Dies
How to Prompt For Yes/No/Cancel Input in a Linux Shell Script
Are There Any Standard Exit Status Codes in Linux
How to Change the Number of Open Files Limit in Linux
What's the Best Way to Send a Signal to All Members of a Process Group
How to Write Standard Error to a File While Using "Tee" With a Pipe
Filter Log File Entries Based on Date Range
Can't Call C Standard Library Function on 64-Bit Linux from Assembly (Yasm) Code
How to Merge Two "Ar" Static Libraries into One
How to Print a Character in Linux X86 Nasm
How to Generate a List of Files With Their Absolute Path in Linux
How to Get Full Path of a File
How to Run a Shell Script on a Unix Console or MAC Terminal
How to Get the Process Id to Kill a Nohup Process
Difference Between "#!/Usr/Bin/Env Bash" and "#!/Usr/Bin/Bash"