Kill a process that keeps restarting












13














What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.



I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>.



$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)


It's not a Zombie process.



$ ps -Al

4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python


I have even tried sudo pkill -f <processname> with no luck. It doesn't want to die.



Update:



It's parent process is sh whose parent is sudo as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.










share|improve this question
























  • Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
    – Patrick
    Sep 29 '14 at 12:50










  • Yes it doesn't want to die forever. Wakes up like it never died :(
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:02
















13














What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.



I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>.



$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)


It's not a Zombie process.



$ ps -Al

4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python


I have even tried sudo pkill -f <processname> with no luck. It doesn't want to die.



Update:



It's parent process is sh whose parent is sudo as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.










share|improve this question
























  • Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
    – Patrick
    Sep 29 '14 at 12:50










  • Yes it doesn't want to die forever. Wakes up like it never died :(
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:02














13












13








13


5





What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.



I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>.



$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)


It's not a Zombie process.



$ ps -Al

4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python


I have even tried sudo pkill -f <processname> with no luck. It doesn't want to die.



Update:



It's parent process is sh whose parent is sudo as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.










share|improve this question















What if 'kill -9' does not work? or How to kill a script which starts new processes? doesn't help me in anyway.



I have a python script which starts automatically with another process id using the same port when killed using sudo kill -9 <pid>.



$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 13242 ubuntu 3u IPv4 64592 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill -9 13242
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16106 ubuntu 3u IPv4 74792 0t0 TCP localhost:3002 (LISTEN)
$ sudo kill 16106
$ lsof -i :3002
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python 16294 ubuntu 3u IPv4 75677 0t0 TCP localhost:3002 (LISTEN)


It's not a Zombie process.



$ ps -Al

4 S 0 16289 1 0 80 0 - 12901 poll_s ? 00:00:00 sudo
4 S 1000 16293 16289 0 80 0 - 1100 wait ? 00:00:00 sh
0 S 1000 16294 16293 0 80 0 - 34632 poll_s ? 00:00:00 python


I have even tried sudo pkill -f <processname> with no luck. It doesn't want to die.



Update:



It's parent process is sh whose parent is sudo as mentioned in the above table. I am not sure if it is safe to kill these abruptly. Also this is a shared ubuntu server.







process kill






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 13 '17 at 12:36









Community

1




1










asked Sep 29 '14 at 12:40









Lakshminarayanan Guptha

68117




68117












  • Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
    – Patrick
    Sep 29 '14 at 12:50










  • Yes it doesn't want to die forever. Wakes up like it never died :(
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:02


















  • Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
    – Patrick
    Sep 29 '14 at 12:50










  • Yes it doesn't want to die forever. Wakes up like it never died :(
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:02
















Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
– Patrick
Sep 29 '14 at 12:50




Looks like it's dying just fine. Your lsof output shows a new pid every single time. The process is simply restarting.
– Patrick
Sep 29 '14 at 12:50












Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02




Yes it doesn't want to die forever. Wakes up like it never died :(
– Lakshminarayanan Guptha
Sep 29 '14 at 13:02










2 Answers
2






active

oldest

votes


















23














Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.



To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).






share|improve this answer























  • Its parent is sh whose parent is sudo. Is it ok to kill them?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:09












  • Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
    – peterph
    Sep 29 '14 at 13:13












  • Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:25












  • Yes, I was thinking about it... :)
    – peterph
    Sep 29 '14 at 13:33










  • ps faux for the win, thanks!
    – hoitomt
    Aug 28 '17 at 17:25



















4














If you know the listening port of the process, you can use fuser with -k flag.



Something like,



fuser -k 3002/tcp





share|improve this answer





















    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',
    autoActivateHeartbeat: false,
    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
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f158194%2fkill-a-process-that-keeps-restarting%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    23














    Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.



    To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).






    share|improve this answer























    • Its parent is sh whose parent is sudo. Is it ok to kill them?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:09












    • Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
      – peterph
      Sep 29 '14 at 13:13












    • Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:25












    • Yes, I was thinking about it... :)
      – peterph
      Sep 29 '14 at 13:33










    • ps faux for the win, thanks!
      – hoitomt
      Aug 28 '17 at 17:25
















    23














    Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.



    To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).






    share|improve this answer























    • Its parent is sh whose parent is sudo. Is it ok to kill them?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:09












    • Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
      – peterph
      Sep 29 '14 at 13:13












    • Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:25












    • Yes, I was thinking about it... :)
      – peterph
      Sep 29 '14 at 13:33










    • ps faux for the win, thanks!
      – hoitomt
      Aug 28 '17 at 17:25














    23












    23








    23






    Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.



    To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).






    share|improve this answer














    Starts automatically with another process ID means that it is a different process. Thus there is a parent process, which monitors its children, and if one dies, it gets respawned by the parent. If you want to stop the service completely, find out how to stop the parent process. Killing it with SIGKILL is of course one of the options, but probably not The Right OneTM, since the service monitor might need to do some cleanup to shut down properly.



    To find the monitor process, you might need to inspect the whole process list, since the actual listeners might dissociate themselves from their parent (usually by the fork() + setsid() combo). In this case, I find the output of ps faux (from procps at least, might vary for other implementations) rather handy - it lists all processes in a hierarchical tree. Unless there has been a PID wrap (see also wikipedia), the monitor PID should be smaller than PID of any of the listeners (unless of course you hit a PID-wraparound).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 9 hours ago

























    answered Sep 29 '14 at 13:02









    peterph

    23k24457




    23k24457












    • Its parent is sh whose parent is sudo. Is it ok to kill them?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:09












    • Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
      – peterph
      Sep 29 '14 at 13:13












    • Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:25












    • Yes, I was thinking about it... :)
      – peterph
      Sep 29 '14 at 13:33










    • ps faux for the win, thanks!
      – hoitomt
      Aug 28 '17 at 17:25


















    • Its parent is sh whose parent is sudo. Is it ok to kill them?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:09












    • Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
      – peterph
      Sep 29 '14 at 13:13












    • Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
      – Lakshminarayanan Guptha
      Sep 29 '14 at 13:25












    • Yes, I was thinking about it... :)
      – peterph
      Sep 29 '14 at 13:33










    • ps faux for the win, thanks!
      – hoitomt
      Aug 28 '17 at 17:25
















    Its parent is sh whose parent is sudo. Is it ok to kill them?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:09






    Its parent is sh whose parent is sudo. Is it ok to kill them?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:09














    Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
    – peterph
    Sep 29 '14 at 13:13






    Parent of which process? The one listening on port 3002? In that case list all processes and guess which one is the monitor. With linux procps, I usually find the output of ps -faux to be informative enough. Also note, that PID of the monitor should be smaller than the PID of the actual listener (unless you have the system up for some time and PIDs already wrapped since the service has been started of course).
    – peterph
    Sep 29 '14 at 13:13














    Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:25






    Great. ps -faux helped to start killing from the parent. Can you please update your answer with the solution from the comment?
    – Lakshminarayanan Guptha
    Sep 29 '14 at 13:25














    Yes, I was thinking about it... :)
    – peterph
    Sep 29 '14 at 13:33




    Yes, I was thinking about it... :)
    – peterph
    Sep 29 '14 at 13:33












    ps faux for the win, thanks!
    – hoitomt
    Aug 28 '17 at 17:25




    ps faux for the win, thanks!
    – hoitomt
    Aug 28 '17 at 17:25













    4














    If you know the listening port of the process, you can use fuser with -k flag.



    Something like,



    fuser -k 3002/tcp





    share|improve this answer


























      4














      If you know the listening port of the process, you can use fuser with -k flag.



      Something like,



      fuser -k 3002/tcp





      share|improve this answer
























        4












        4








        4






        If you know the listening port of the process, you can use fuser with -k flag.



        Something like,



        fuser -k 3002/tcp





        share|improve this answer












        If you know the listening port of the process, you can use fuser with -k flag.



        Something like,



        fuser -k 3002/tcp






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Sep 29 '14 at 13:20









        Ramesh

        23.2k32101181




        23.2k32101181






























            draft saved

            draft discarded




















































            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%2f158194%2fkill-a-process-that-keeps-restarting%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

            Accessing regular linux commands in Huawei's Dopra Linux

            Can't connect RFCOMM socket: Host is down

            Kernel panic - not syncing: Fatal Exception in Interrupt