“kill ” not really killing the process, why?











up vote
101
down vote

favorite
25












I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200 where 2200 is my PID and the process is not killed. After few minutes wait is still in the top and ps aux.
I have even tried typing it with sudo - no results.



Any ideas why it would be like that ?





EDIT



I have found a weird dependency, where fg updates the processes list:



x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps









share|improve this question
























  • What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
    – htorque
    Sep 3 '11 at 7:49










  • The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
    – Patryk
    Sep 3 '11 at 7:54






  • 2




    If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
    – nos
    Jun 10 '14 at 8:09















up vote
101
down vote

favorite
25












I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200 where 2200 is my PID and the process is not killed. After few minutes wait is still in the top and ps aux.
I have even tried typing it with sudo - no results.



Any ideas why it would be like that ?





EDIT



I have found a weird dependency, where fg updates the processes list:



x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps









share|improve this question
























  • What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
    – htorque
    Sep 3 '11 at 7:49










  • The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
    – Patryk
    Sep 3 '11 at 7:54






  • 2




    If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
    – nos
    Jun 10 '14 at 8:09













up vote
101
down vote

favorite
25









up vote
101
down vote

favorite
25






25





I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200 where 2200 is my PID and the process is not killed. After few minutes wait is still in the top and ps aux.
I have even tried typing it with sudo - no results.



Any ideas why it would be like that ?





EDIT



I have found a weird dependency, where fg updates the processes list:



x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps









share|improve this question















I am trying to improve my command line skills and I have encountered a problem where I cannot kill a process. I type kill 2200 where 2200 is my PID and the process is not killed. After few minutes wait is still in the top and ps aux.
I have even tried typing it with sudo - no results.



Any ideas why it would be like that ?





EDIT



I have found a weird dependency, where fg updates the processes list:



x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2202 pts/0 00:00:00 top
2258 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2200 pts/0 00:00:00 top
2620 pts/0 00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
PID TTY TIME CMD
1723 pts/0 00:00:00 bash
2621 pts/0 00:00:00 ps






command-line process






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jun 6 '16 at 12:26









muru

134k19283483




134k19283483










asked Sep 3 '11 at 7:47









Patryk

4,361255996




4,361255996












  • What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
    – htorque
    Sep 3 '11 at 7:49










  • The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
    – Patryk
    Sep 3 '11 at 7:54






  • 2




    If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
    – nos
    Jun 10 '14 at 8:09


















  • What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
    – htorque
    Sep 3 '11 at 7:49










  • The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
    – Patryk
    Sep 3 '11 at 7:54






  • 2




    If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
    – nos
    Jun 10 '14 at 8:09
















What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49




What process was that? Did you check if the process maybe was defunct? In that case you'd need to kill the parent process.
– htorque
Sep 3 '11 at 7:49












The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
– Patryk
Sep 3 '11 at 7:54




The process is top (as listed in the edit). I just wanted to try putting program to work into background and then bringing it back.
– Patryk
Sep 3 '11 at 7:54




2




2




If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
– nos
Jun 10 '14 at 8:09




If you suspend a process with CTRL-z, it'll block most signals as long as it's suspended (i.e. until you do a fg or bg for the process)
– nos
Jun 10 '14 at 8:09










6 Answers
6






active

oldest

votes

















up vote
159
down vote



accepted










Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:



kill -9 {PID}


Learn more by reading the manual page:



man kill





share|improve this answer



















  • 18




    also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
    – Lie Ryan
    Sep 3 '11 at 11:49








  • 15




    If that process steps out of line then it's KILL DASH NINE!
    – scottl
    Sep 5 '11 at 4:22






  • 3




    And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
    – user606723
    Sep 6 '11 at 15:25










  • You can also just use pkill process, where process is the name of the process in stead of the process ID.
    – RobinJ
    Sep 6 '11 at 17:26






  • 2




    The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
    – rbaleksandar
    Jul 17 '15 at 14:08


















up vote
33
down vote













If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.



You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.



One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.






share|improve this answer

















  • 2




    This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
    – Sheljohn
    Jul 6 '14 at 20:13


















up vote
7
down vote













Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:



kill - send a signal to a process



The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.



Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.



If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].






share|improve this answer






























    up vote
    2
    down vote













    It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.






    share|improve this answer

















    • 1




      So how to find attached terminal?
      – ruX
      Mar 21 '13 at 16:58


















    up vote
    0
    down vote













    From within C++, I executed:



    kill(4024, SIGKILL);


    And on a linux(Ubuntu) terminal,



    $ ps -ax | grep my_su


    The output was:



    4024 pts/1    Z+     0:00 [my_subscriber] <defunct>


    Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!






    share|improve this answer




























      up vote
      0
      down vote













      You also may use kill -l to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.



      Note: as others may have mentioned, the use of kill -9 {PID} is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.






      share|improve this answer























        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "89"
        };
        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: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        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
        });


        }
        });














         

        draft saved


        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f59811%2fkill-pid-not-really-killing-the-process-why%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        6 Answers
        6






        active

        oldest

        votes








        6 Answers
        6






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        159
        down vote



        accepted










        Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:



        kill -9 {PID}


        Learn more by reading the manual page:



        man kill





        share|improve this answer



















        • 18




          also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
          – Lie Ryan
          Sep 3 '11 at 11:49








        • 15




          If that process steps out of line then it's KILL DASH NINE!
          – scottl
          Sep 5 '11 at 4:22






        • 3




          And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
          – user606723
          Sep 6 '11 at 15:25










        • You can also just use pkill process, where process is the name of the process in stead of the process ID.
          – RobinJ
          Sep 6 '11 at 17:26






        • 2




          The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
          – rbaleksandar
          Jul 17 '15 at 14:08















        up vote
        159
        down vote



        accepted










        Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:



        kill -9 {PID}


        Learn more by reading the manual page:



        man kill





        share|improve this answer



















        • 18




          also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
          – Lie Ryan
          Sep 3 '11 at 11:49








        • 15




          If that process steps out of line then it's KILL DASH NINE!
          – scottl
          Sep 5 '11 at 4:22






        • 3




          And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
          – user606723
          Sep 6 '11 at 15:25










        • You can also just use pkill process, where process is the name of the process in stead of the process ID.
          – RobinJ
          Sep 6 '11 at 17:26






        • 2




          The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
          – rbaleksandar
          Jul 17 '15 at 14:08













        up vote
        159
        down vote



        accepted







        up vote
        159
        down vote



        accepted






        Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:



        kill -9 {PID}


        Learn more by reading the manual page:



        man kill





        share|improve this answer














        Processes can ignore some signals. If you send SIGKILL it will not be able to ignore it (and neither catch it to do cleanups). Try:



        kill -9 {PID}


        Learn more by reading the manual page:



        man kill






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Sep 3 '11 at 8:18









        Lekensteyn

        119k47262353




        119k47262353










        answered Sep 3 '11 at 8:09









        Michał Šrajer

        16.4k42528




        16.4k42528








        • 18




          also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
          – Lie Ryan
          Sep 3 '11 at 11:49








        • 15




          If that process steps out of line then it's KILL DASH NINE!
          – scottl
          Sep 5 '11 at 4:22






        • 3




          And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
          – user606723
          Sep 6 '11 at 15:25










        • You can also just use pkill process, where process is the name of the process in stead of the process ID.
          – RobinJ
          Sep 6 '11 at 17:26






        • 2




          The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
          – rbaleksandar
          Jul 17 '15 at 14:08














        • 18




          also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
          – Lie Ryan
          Sep 3 '11 at 11:49








        • 15




          If that process steps out of line then it's KILL DASH NINE!
          – scottl
          Sep 5 '11 at 4:22






        • 3




          And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
          – user606723
          Sep 6 '11 at 15:25










        • You can also just use pkill process, where process is the name of the process in stead of the process ID.
          – RobinJ
          Sep 6 '11 at 17:26






        • 2




          The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
          – rbaleksandar
          Jul 17 '15 at 14:08








        18




        18




        also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
        – Lie Ryan
        Sep 3 '11 at 11:49






        also note that in some very specific circumstances, a process can be in a zombie/defunct state that even SIGKILL cannot kill the process. In that case, you will have to find the parent process and kill the parent process.
        – Lie Ryan
        Sep 3 '11 at 11:49






        15




        15




        If that process steps out of line then it's KILL DASH NINE!
        – scottl
        Sep 5 '11 at 4:22




        If that process steps out of line then it's KILL DASH NINE!
        – scottl
        Sep 5 '11 at 4:22




        3




        3




        And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
        – user606723
        Sep 6 '11 at 15:25




        And sometimes there is no parent process, in which case you're just screwed. The only way to remove such a process is to reboot the machine.
        – user606723
        Sep 6 '11 at 15:25












        You can also just use pkill process, where process is the name of the process in stead of the process ID.
        – RobinJ
        Sep 6 '11 at 17:26




        You can also just use pkill process, where process is the name of the process in stead of the process ID.
        – RobinJ
        Sep 6 '11 at 17:26




        2




        2




        The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
        – rbaleksandar
        Jul 17 '15 at 14:08




        The name of the kill command continues to be misleading for many, many users (including me at the beginning). One assumes that when you say "kill X" this means really kill the X and not do something else. I understand this won't change a thing but I wish they have picked a more elaborative name...
        – rbaleksandar
        Jul 17 '15 at 14:08












        up vote
        33
        down vote













        If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.



        You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.



        One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.






        share|improve this answer

















        • 2




          This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
          – Sheljohn
          Jul 6 '14 at 20:13















        up vote
        33
        down vote













        If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.



        You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.



        One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.






        share|improve this answer

















        • 2




          This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
          – Sheljohn
          Jul 6 '14 at 20:13













        up vote
        33
        down vote










        up vote
        33
        down vote









        If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.



        You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.



        One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.






        share|improve this answer












        If kill is invoked without any parameter, it sends the signal number 15 (SIGTERM). This signal can be ignored by the process. This signal notifies the process to clean his things up and then end correctly by himself. That's the nice way.



        You can also "send" the signal number 9 (SIGKILL) that cannot be ignored by the process. The process will even not recognize it, because the kernel ends the process, not the process itself. That's the evil way.



        One says kill -9 <pid> always works. That's a misbelief. There are situations where even kill -9 does not kill the process. For example when a process has the state D (uninterruptable sleep). A process comes into this state everytime it waits for I/O (normally not very long). So, if a process waits for I/O (on a defect harddisk for example) and it is not programmed properly (with a timeout), then you simply cannot kill the process. No matter what you do. You just can try to make the file accessible that the process continues.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jun 10 '14 at 6:22









        chaos

        18.9k85667




        18.9k85667








        • 2




          This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
          – Sheljohn
          Jul 6 '14 at 20:13














        • 2




          This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
          – Sheljohn
          Jul 6 '14 at 20:13








        2




        2




        This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
        – Sheljohn
        Jul 6 '14 at 20:13




        This is very helpful, I have experienced this several times because of hanging I/O access on network disks and I was wondering why I couldn't kill processes that froze. Is there more documentation on this specific issue and how to get around it?
        – Sheljohn
        Jul 6 '14 at 20:13










        up vote
        7
        down vote













        Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:



        kill - send a signal to a process



        The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.



        Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.



        If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].






        share|improve this answer



























          up vote
          7
          down vote













          Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:



          kill - send a signal to a process



          The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.



          Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.



          If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].






          share|improve this answer

























            up vote
            7
            down vote










            up vote
            7
            down vote









            Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:



            kill - send a signal to a process



            The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.



            Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.



            If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].






            share|improve this answer














            Despite it's name kill doesn't actually kill processes, it sends signals to it. From the man page:



            kill - send a signal to a process



            The default signal sent by kill [pid] is SIGTERM which usually but not necessarily asks the process to terminate. It's quite possible to write a program that plays a happy tune when you send the SIGTERM signal to it, but not recommended.



            Another common signal is SIGHUP which is often used to ask a program to reread its configuration files.



            If you really want to kill a program you need to use the SIGKILL signal by doing kill -9 [pid].







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Sep 6 '11 at 17:35

























            answered Sep 6 '11 at 11:51









            danne

            422410




            422410






















                up vote
                2
                down vote













                It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.






                share|improve this answer

















                • 1




                  So how to find attached terminal?
                  – ruX
                  Mar 21 '13 at 16:58















                up vote
                2
                down vote













                It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.






                share|improve this answer

















                • 1




                  So how to find attached terminal?
                  – ruX
                  Mar 21 '13 at 16:58













                up vote
                2
                down vote










                up vote
                2
                down vote









                It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.






                share|improve this answer












                It sounds like you might be suspending a process (perhaps by pressing Ctrl-Z in the terminal). In this state, your process will not respond to a SIGTERM as it is frozen. Running 'fg' thaws the process, so it can pick up the signal and self-terminate. That could explain why 'fg' appears to update the process list.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Sep 6 '11 at 15:00









                user24497

                211




                211








                • 1




                  So how to find attached terminal?
                  – ruX
                  Mar 21 '13 at 16:58














                • 1




                  So how to find attached terminal?
                  – ruX
                  Mar 21 '13 at 16:58








                1




                1




                So how to find attached terminal?
                – ruX
                Mar 21 '13 at 16:58




                So how to find attached terminal?
                – ruX
                Mar 21 '13 at 16:58










                up vote
                0
                down vote













                From within C++, I executed:



                kill(4024, SIGKILL);


                And on a linux(Ubuntu) terminal,



                $ ps -ax | grep my_su


                The output was:



                4024 pts/1    Z+     0:00 [my_subscriber] <defunct>


                Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!






                share|improve this answer

























                  up vote
                  0
                  down vote













                  From within C++, I executed:



                  kill(4024, SIGKILL);


                  And on a linux(Ubuntu) terminal,



                  $ ps -ax | grep my_su


                  The output was:



                  4024 pts/1    Z+     0:00 [my_subscriber] <defunct>


                  Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!






                  share|improve this answer























                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    From within C++, I executed:



                    kill(4024, SIGKILL);


                    And on a linux(Ubuntu) terminal,



                    $ ps -ax | grep my_su


                    The output was:



                    4024 pts/1    Z+     0:00 [my_subscriber] <defunct>


                    Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!






                    share|improve this answer












                    From within C++, I executed:



                    kill(4024, SIGKILL);


                    And on a linux(Ubuntu) terminal,



                    $ ps -ax | grep my_su


                    The output was:



                    4024 pts/1    Z+     0:00 [my_subscriber] <defunct>


                    Seemingly, it (4024) still surviving. However, as soon as I terminated the parent process which called the above "kill" statement, 4024 didn't appear any more. Now I judge "defunct" process is nothing more than a line displayed and decided to ignore it. I hope my experience could help someone out there. Cheers!







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Mar 10 '16 at 23:51









                    Park JongBum

                    1163




                    1163






















                        up vote
                        0
                        down vote













                        You also may use kill -l to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.



                        Note: as others may have mentioned, the use of kill -9 {PID} is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.






                        share|improve this answer



























                          up vote
                          0
                          down vote













                          You also may use kill -l to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.



                          Note: as others may have mentioned, the use of kill -9 {PID} is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.






                          share|improve this answer

























                            up vote
                            0
                            down vote










                            up vote
                            0
                            down vote









                            You also may use kill -l to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.



                            Note: as others may have mentioned, the use of kill -9 {PID} is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.






                            share|improve this answer














                            You also may use kill -l to display the supported signals by your architecture, and learn more about the signal you may wish to use to properly send a signal.



                            Note: as others may have mentioned, the use of kill -9 {PID} is not recommended unless its a zombie process. once a process receives a SIGKILL will shutdown immediately without cleaning or any other proper procedures.







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Nov 19 at 10:52

























                            answered Nov 19 at 10:47









                            amrx

                            1,135915




                            1,135915






























                                 

                                draft saved


                                draft discarded



















































                                 


                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f59811%2fkill-pid-not-really-killing-the-process-why%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

                                Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

                                ComboBox Display Member on multiple fields

                                Is it possible to collect Nectar points via Trainline?