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 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)?

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

1 Answer 1


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

  • 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, 2020 at 16:30

You must log in to answer this question.

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