1

According to the POSIX standard regarding signals (see "Standard signals" section), both SIGKILL and SIGINT have as default action Term. However, this seems not to be the case when the receiving process has been stopped via SIGSTOP (or SIGTSTP).

For the sake of simplicity, let's say I create a program with an infinite loop:

int main(){
   while(1);
}

compile and run it

$ ./program

Then I press CtrlZ to stop it. This causes a SIGTSTP signal to be delivered to this process. Now, if I send a SIGINT signal to the process via kill -SIGINT pid, and look at the process table: ps -aux, I see that it has not been terminated. However, if I send a kill -SIGKILL pid it does get terminated.

Why does SIGINT not behave in the same way as SIGKILL, if they both have the same default action (i.e. Term)?

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
mateleco
  • 210
  • 1
  • 8
  • 2
    `INT` needs to be received by the process (which can't happen while it is stopped). `KILL` is never actually received by the process anyway. This is not an answer as it does not show any example or references. – Kusalananda Nov 22 '20 at 09:01
  • Try sending a `SIGTERM` since a nice shell will also send a `SIGCONT` in this case. – schily Nov 22 '20 at 14:43

1 Answers1

3

SIGKILL will terminate a process by default and cannot be blocked, whereas SIGINT will terminate a process by default but can be blocked. Since you moved the process to the background with CtrlZ (SIGTSTP), the SIGINT signal will be blocked and will only be delivered to the process after it resumes its execution (SIGCONT).

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
Meow
  • 456
  • 4
  • 7
  • 2
    Thanks. That makes a lot of sense, because when I execute `kill -SIGCONT pid`, SIGINT gets unblocked and the pending SIGINT signal is delivered, causing the process to terminate. – mateleco Nov 22 '20 at 16:30