0

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:

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:

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

5
  • 1
    "Interrupting" (INT) a program does not necessarily mean "terminating" (TERM) the program. See e.g. how a shell handles the two signals (ignores TERM and lets INT interrupt a builtin command).
    – Kusalananda
    May 17 at 19:07
  • @ilkkachu Why do you think SIGINT does the same than SIGTERM only "theoretically"? About the "theoretically" - it is based or according with the answer in the post and not according with an official page. May 17 at 20:58
  • @Kusalananda agree, but, according with the answer in the other post, both do the same May 17 at 20:58
  • To both - in the answer indicates: "The default action for SIGINT is the same sort of process termination as the default action for SIGTERM" May 17 at 21:03
  • @ilkkachu - right now for more simplicity lets take the question: Or are you just asking why there are two signals that seem to just do the same thing? May 17 at 21:34

2 Answers 2

3

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.

7
  • Pls consider to add a note to indicate explicitly if is safe trigger SIGINT through ctrl + c May 17 at 22:50
  • @ManuelJordan, mhh. Probably the worst that can happen is that the process in question just terminates. But it depends on the program in question, and if it's "safe" for the process to terminate depends on what is meant with "safety" in the context.
    – ilkkachu
    May 18 at 0:00
  • 1
    @ManuelJordan, depends on what data there is, and what the program does on receiving the signal. The default action of both SIGINT and SIGTERM is the same: the termination of the process. Pretty much the same as the program calling _exit(). Anything in userspace memory is lost. Any OS resources are handled by the kernel, the same way as always when a program exits. And again that's the default: the program can set a signal handler and do whatever it wants when receiving either of those signals.
    – ilkkachu
    May 18 at 14:46
  • 1
    @ManuelJordan, if you have a sensible, well-made program, it'll try to keep things in line even if it gets SIGINT or SIGTERM (they're rather common anyway). If the developer has been lazy, they might cause problems. And if the program is insane, it'll run rm -rf "$HOME" when getting SIGINT. In general, we don't know.
    – ilkkachu
    May 18 at 14:47
  • 1
    @ManuelJordan, mm, yeah, signals do interrupt the normal program flow. They can cause system calls to return early (e.g. a read() waiting for input can return with EINTR, which the program has to deal with), and if there's a signal handler set up, the program will jump to run the handler function immediately, interrupting what ever it was it was doing, and regardless of what that was (a possible source of some issues too, but that's another thing). But it's stuff that the program can be made to deal with, and mostly a headache for the programmer...
    – ilkkachu
    May 18 at 16:04
-1

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".

2
  • “an application can catch and process any signal it likes, however it likes” — no, some signals can’t be caught. May 17 at 20:40
  • 1
    "The SIGINT was created first [...] Then SIGKILL was added" -- do you have a source for this piece of history? About the order the signals were added? "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..." -- are you sure? Currently SIGKILL is the uncatchable one, and SIGTERM the regular one.
    – ilkkachu
    May 17 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.