Apart from the most violent kill -9 (SIGKILL), I don't quite understand the difference between the 3 other common signals (here) -HUP (1), -INT (2), and -TERM (15).

In which scenarios would one work and the other not?

In general when does -9 (-KILL) fail?

To me, they seem to ask the process to terminate gracefully, without saving. Rating the harshness, I would put -HUP < -TERM < -INT < -KILL.

  • 3
    HUP doesn't necessarily mean the program will quit. Some programs use SIGHUP to reload configuration files. SIGKILL fails, or rather is postponed, when the process is in uninterruptible sleep.
    – muru
    Commented Dec 23, 2015 at 18:47

1 Answer 1


SIGKILL never fails to kill a running process, that's the point. Other signals exist to give the application a chance to react.

The default behavior of SIGINT, SIGTERM, SIGQUIT and SIGHUP is to kill the program. However applications are allowed to install a handler for these signals. So the actual behavior of applications when they receive these signals is a matter of convention (which each application may or may not follow), not of system design.

SIGINT is the “weakest” of the lot. Its conventional meaning is “stop what you're doing right now and wait for further user input”. It's the signal generated by Ctrl+C in a terminal. Non-interactive programs generally treat it like SIGTERM.

SIGTERM is the “normal” kill signal. It tells the application to exit cleanly. The application might take time to save its state, to free resources such as temporary files that would otherwise stay behind, etc. An application that doesn't want to be interrupted during a critical application might ignore SIGTERM for a while.

SIGHUP is about the same as SIGTERM in terms of harshness, but it has a specific role because it's automatically sent to applications running in a terminal when the user disconnects from that terminal (etymologically, because the user was connecting via a telephone line and the modem hung up). SIGHUP is often involuntary, unlike SIGTERM which has to be sent explicitly, so applications should try to save their state on a SIGHUP. SIGHUP also has a completely different conventional meaning for non-user-facing applications (daemons), which is to reload their configuration file.

SIGQUIT is the harshest of the ignorable signals. It's meant to be used when an application is misbehaving and needs to be killed now, and by default it traditionally left a core dump file (modern systems where most users wouldn't know what a core file is tend to not produce them by default). Applications can set a handler but should do very little (in particular not save any state) because the intent of SIGQUIT is to be used when something is seriously wrong.

  • Can you elaborate more on "save their state" ? If I am in a text editor and I kill it, I suppose the content is not saved.
    – Kenny
    Commented Dec 24, 2015 at 10:07
  • 3
    @Kenny Most editors won't save the file, because you might have made temporary modifications that you didn't intend to save. Advanced editors (e.g. vi, emacs) have an auto-save file where they save data from time to time; on SIGHUP they would typically make sure that the auto-save file is up to date. Commented Dec 24, 2015 at 12:00
  • 1
    SIGQUIT should not only leave a core dump, but also omit most of/all of the cleanups (like deleting temporary files); I always think of it of a somewhat debugging signal; "Certain kinds of cleanups are best omitted in handling SIGQUIT. For example, if the program creates temporary files, it should handle the other termination requests by deleting the temporary files. But it is better for SIGQUIT not to delete them, so that the user can examine them in conjunction with the core dump." gnu.org/software/libc/manual/html_node/Termination-Signals.html
    – SantaXL
    Commented Dec 15, 2019 at 14:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .