When is mandatory send SIGINT programmatically?

Question

I know the recommendable way to terminate a foreground process is through the SIGTERM signal, it because it gives the opportunity to the process itself to clean/release resources. This signal only can be generated/send through a command, it through any of the kill pkill killall commands - until here I am ok. Furthermore it is the default signal for these commands.

Now, I know the SIGINT signal interrupts a process. Therefore "similar" as terminate.

But I read the following answer (extract) from:

• How does SIGINT relate to the other termination signals such as SIGTERM, SIGQUIT and SIGKILL?

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;

Until here according with the answer SIGINT is triggered by keys combination (ctrl + c) and theoretically SIGINT does the same than SIGTERM, it about to: give the program itself the opportunity to clean/release resources.

To be honest after to read many tutorials, I couldn't find and confirm that information explicitly. It for example from:

• signal(7) — Linux manual page
• 24.2.2 Termination Signals

In many places for these signals are used the interrupts and terminates terms.

Furthermore, from the same answer exists the @Jonathan Leffler's comment (extract) as:

This is the key point: SIGINT and SIGQUIT can be generated from the terminal using single characters, while the program is running. The other signals have to be generated by another program, somehow (eg by the kill command). SIGINT is less violent than SIGQUIT; the latter produces a core dump

Until here as a possible conclusion: SIGINT can be triggered through either key combinations or command and SIGTERM only by command.

Reason of this post: If theoretically SIGINT does the same than SIGTERM

Question

• When is mandatory send SIGINT programmatically?

It appears in kill -l, so can be use it.

Extra Questions

Again, if theoretically SIGINT does the same than SIGTERM - and both can be ignored/blocked/handled

• Why was created SIGINT?
• Why ctrl + c was not assigned from the beginning to SIGTERM?

To be honest I assumed that SIGINT is not safe because it interrupts the process and therefore would leave some data in a not consistent/integral state

Answer 1

The default action of both SIGINT and SIGTERM (as well as that of many other signals) is to terminate the process. That's documented in e.g. the Linux man page signal(7), see the table under "Standard signals", quoted in part below. It's quite true in practice too.

Part of the table there:

       Signal      Standard   Action   Comment
────────────────────────────────────────────────────────────────────────
       SIGHUP       P1990      Term    Hangup detected on controlling terminal
                                       or death of controlling process
       SIGINT       P1990      Term    Interrupt from keyboard
       SIGKILL      P1990      Term    Kill signal
       SIGTERM      P1990      Term    Termination signal

Now, that's the default action. For most signals, the program receiving them can catch them by setting a signal handler function in advance, or ignore them completely. Knowing that a SIGINT is usually sent by a user hitting Ctrl-C, and SIGTERM is usually sent by some other program asking the receiving one to exit, a program can decide to deal with them in different ways.

An interactive program might decide to just end any long-running tasks on SIGINT instead of exiting immediately, leaving the user the choice to exit or to do something different. All the while still exiting on SIGTERM. Then again, a simpler program might set the same handler for both of them (and possibly a few others, like SIGHUP): one that saves all data and exits.

As an example, the interactive Bash shell I tried on my Debian clears the current command line on SIGINT without executing anything; ignores SIGTERM (somewhat surprisingly, but it may have to do with sending signals to whole process groups); and exits on SIGHUP (because SIGHUP means the terminal connection went away, so there's no point in trying to read further commands).

Most signals allow the receiving process to do any cleanup it likes before (possibly) exiting. The two exceptional signals are SIGKILL and SIGSTOP, which can't be caught or ignored, but they unconditionally and immediately destroy or stop the process, without letting it do any cleanup. (Though note that the kernel would still do any cleanup needed for OS resources, the cleanup here is more about unsaved data in the process memory.)

Of course there are still other signals that also default to terminating the process. Like SIGALRM, which is sent by the timer set with the alarm() system call. While the default behaviour can be useful in some cases, it's far more useful as a generic alarm clock, e.g. telling the program to do some periodic task.

Answer 2

When is mandatory send SIGINT programmatically?

The answer is: never. It is never mandatory to send a signal. Signals are for catching, not for sending.

Why was created SIGINT? Why ctrl + c was not assigned from the beginning to SIGTERM?

The answer to that lies in the signal codes - SIGINT=2, SIGKILL=9, SIGTERM=15. The SIGINT was created first and assigned to ^C. Then people found, that ^C sometime have to be processed by the application (or can be processed), so the new 'special' SIGKILL was added for use by kill tool. Then this signal was caught by many applications and SIGTERM was invented in the hopes that this signal would be uncatchable...

The point is: all signals described in man 7 signal as terminate application does exactly that - terminate, by default, should terminate, usually terminate... But since an application can catch and process any signal it likes, however it likes - it all become more of a suggestion, than a rule. Keyword here is "tradition".