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(){

compile and run it

$ ./program

Then I press Ctrl+Z 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)?

  • 1
    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 9:01
  • Try sending a SIGTERM since a nice shell will also send a SIGCONT in this case. – schily Nov 22 '20 at 14:43

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 ctrl-z (SIGTSTP), the SIGINT signal will be blocked and will only be delivered to the process after it resumes its execution (SIGCONT).

  • 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

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.