What does a program do when it's sent SIGKILL signal?











up vote
17
down vote

favorite
5












When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really.
So, what's happening during those minutes?










share|improve this question









New contributor




haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
























    up vote
    17
    down vote

    favorite
    5












    When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really.
    So, what's happening during those minutes?










    share|improve this question









    New contributor




    haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      up vote
      17
      down vote

      favorite
      5









      up vote
      17
      down vote

      favorite
      5






      5





      When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really.
      So, what's happening during those minutes?










      share|improve this question









      New contributor




      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      When I used killall -9 name to kill a program, the state become zombie. Some minutes later, it stopped really.
      So, what's happening during those minutes?







      kill






      share|improve this question









      New contributor




      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 3 hours ago









      Monty Harder

      22215




      22215






      New contributor




      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 14 hours ago









      haikun he

      884




      884




      New contributor




      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      haikun he is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          33
          down vote



          accepted










          The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.



          When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.



          When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.



          If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.



          If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.



          There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)






          share|improve this answer

















          • 2




            What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
            – gidds
            8 hours ago










          • I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
            – haikun he
            7 hours ago






          • 1




            @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
            – zwol
            7 hours ago










          • It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
            – kasperd
            7 hours ago










          • @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
            – kasperd
            7 hours ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "106"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });






          haikun he is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485644%2fwhat-does-a-program-do-when-its-sent-sigkill-signal%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          33
          down vote



          accepted










          The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.



          When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.



          When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.



          If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.



          If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.



          There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)






          share|improve this answer

















          • 2




            What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
            – gidds
            8 hours ago










          • I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
            – haikun he
            7 hours ago






          • 1




            @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
            – zwol
            7 hours ago










          • It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
            – kasperd
            7 hours ago










          • @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
            – kasperd
            7 hours ago















          up vote
          33
          down vote



          accepted










          The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.



          When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.



          When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.



          If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.



          If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.



          There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)






          share|improve this answer

















          • 2




            What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
            – gidds
            8 hours ago










          • I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
            – haikun he
            7 hours ago






          • 1




            @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
            – zwol
            7 hours ago










          • It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
            – kasperd
            7 hours ago










          • @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
            – kasperd
            7 hours ago













          up vote
          33
          down vote



          accepted







          up vote
          33
          down vote



          accepted






          The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.



          When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.



          When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.



          If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.



          If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.



          There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)






          share|improve this answer












          The program actually never receives the SIGKILL signal, as SIGKILL is completely handled by the operating system/kernel.



          When SIGKILL for a specific process is sent, the kernel's scheduler immediately stops giving that process any more CPU time (and interrupts its currently executing threads, if there is any). As a result, the process itself would never get the chance to actually process the information that it has received a SIGKILL. Then other kernel routines are called to remove the process from memory and free all resources it had open at the time. As usual, the parent (PPID) of the killed process is notified of the death of the child process with a SIGCHLD signal.



          When a process is in a "zombie" state it means the process is already dead, but its parent process has not yet acknowledged this by reading the exit code of the dead process using the wait(2) system call. Basically the only resource a zombie process is consuming any more is a slot in the process table that holds its PID, the exit code and some other "vital statistics" of the process at the time of its death.



          If the parent process dies before its children, the orphaned child processes are automatically adopted by PID #1, which has a special duty to keep calling wait(2) so that any orphaned processes won't stick around as zombies.



          If it takes several minutes for a zombie process to clear, it suggests that the parent process of the zombie is struggling or not doing its job properly.



          There is a tongue-in-cheek description on what to do in case of zombie problems in Unix-like operating systems: "You cannot do anything for the zombies themselves, as they are already dead. Instead, kill the evil zombie master!" (i.e. the parent process of the troublesome zombies)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 12 hours ago









          telcoM

          14.8k12043




          14.8k12043








          • 2




            What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
            – gidds
            8 hours ago










          • I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
            – haikun he
            7 hours ago






          • 1




            @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
            – zwol
            7 hours ago










          • It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
            – kasperd
            7 hours ago










          • @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
            – kasperd
            7 hours ago














          • 2




            What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
            – gidds
            8 hours ago










          • I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
            – haikun he
            7 hours ago






          • 1




            @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
            – zwol
            7 hours ago










          • It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
            – kasperd
            7 hours ago










          • @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
            – kasperd
            7 hours ago








          2




          2




          What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
          – gidds
          8 hours ago




          What happens if the process is in a kernel call (e.g. doing I/O) when SIGKILL is sent?
          – gidds
          8 hours ago












          I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
          – haikun he
          7 hours ago




          I think this process will become zombie, and his parent process wait the kernel call finished to recycle the resources.(English is poor,please forgive me.)
          – haikun he
          7 hours ago




          1




          1




          @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
          – zwol
          7 hours ago




          @gidds Either the I/O will be cancelled in order to execute the SIGKILL, or the SIGKILL will be delayed until the I/O completes. This is the difference between 'S' and 'D' sleep states in ps: 'S' is for I/O waits that the kernel can cancel in order to deliver a signal, and 'D' for those it can't.
          – zwol
          7 hours ago












          It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
          – kasperd
          7 hours ago




          It's not entirely accurate to say the schedule immediately stops giving the process CPU time. The kernel side of the signal handling is still executed by that process, but the process will only be executing kernel code so you are right when you say the program never receives the signal. The process will be executing kernel code responsible for most of the cleanup of resources (open files, virtual memory, etc.) The last steps of this cleanup code is to change the process state to zombie and invoke the scheduler. Then it will never be scheduled again.
          – kasperd
          7 hours ago












          @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
          – kasperd
          7 hours ago




          @gidds There are at least four different states that process can be in. It can be running kernel code at the moment or it can be sleeping in one of three different sleep states. The sleep states can either be interruptible, non-interruptible, or non-interruptible except for deadly signals. If it is in non-interruptible sleep it will be left sleeping for as long as it needs and only once it wakes up will it have a chance to die. If it was in one of the other two sleep states it will be woken up immediately and scheduled as soon as there is a CPU available for it.
          – kasperd
          7 hours ago










          haikun he is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          haikun he is a new contributor. Be nice, and check out our Code of Conduct.













          haikun he is a new contributor. Be nice, and check out our Code of Conduct.












          haikun he is a new contributor. Be nice, and check out our Code of Conduct.
















          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485644%2fwhat-does-a-program-do-when-its-sent-sigkill-signal%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

          Mangá

           ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕