Bash script should only kill those instances of another script's that it has launched












10















In the current situation, a certain script 'calling.sh' launches another script 'called.sh' in the background, performs other operations, sleeps for a while, and then terminates 'called.sh' with a pkill called.sh. This works fine.



Then, I would also like to launch 'called.sh' from other terminals as a standalone script at any other time, whether before or after launching calling.sh. These independent instances should not be killed by 'calling.sh'.



How can I achieve this? Intuition says that the calling script should be able to tell the process it started from any other namesakes that are running in the meantime.



As a variant, 'calling.sh' may also launch 'called' which is a symbolic link to 'called.sh'. Does this complicate managing the above situation? Which specific cautions and adjustments does using a symbolic link require?










share|improve this question


















  • 1





    I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

    – Rusi
    Mar 11 at 13:18
















10















In the current situation, a certain script 'calling.sh' launches another script 'called.sh' in the background, performs other operations, sleeps for a while, and then terminates 'called.sh' with a pkill called.sh. This works fine.



Then, I would also like to launch 'called.sh' from other terminals as a standalone script at any other time, whether before or after launching calling.sh. These independent instances should not be killed by 'calling.sh'.



How can I achieve this? Intuition says that the calling script should be able to tell the process it started from any other namesakes that are running in the meantime.



As a variant, 'calling.sh' may also launch 'called' which is a symbolic link to 'called.sh'. Does this complicate managing the above situation? Which specific cautions and adjustments does using a symbolic link require?










share|improve this question


















  • 1





    I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

    – Rusi
    Mar 11 at 13:18














10












10








10


1






In the current situation, a certain script 'calling.sh' launches another script 'called.sh' in the background, performs other operations, sleeps for a while, and then terminates 'called.sh' with a pkill called.sh. This works fine.



Then, I would also like to launch 'called.sh' from other terminals as a standalone script at any other time, whether before or after launching calling.sh. These independent instances should not be killed by 'calling.sh'.



How can I achieve this? Intuition says that the calling script should be able to tell the process it started from any other namesakes that are running in the meantime.



As a variant, 'calling.sh' may also launch 'called' which is a symbolic link to 'called.sh'. Does this complicate managing the above situation? Which specific cautions and adjustments does using a symbolic link require?










share|improve this question














In the current situation, a certain script 'calling.sh' launches another script 'called.sh' in the background, performs other operations, sleeps for a while, and then terminates 'called.sh' with a pkill called.sh. This works fine.



Then, I would also like to launch 'called.sh' from other terminals as a standalone script at any other time, whether before or after launching calling.sh. These independent instances should not be killed by 'calling.sh'.



How can I achieve this? Intuition says that the calling script should be able to tell the process it started from any other namesakes that are running in the meantime.



As a variant, 'calling.sh' may also launch 'called' which is a symbolic link to 'called.sh'. Does this complicate managing the above situation? Which specific cautions and adjustments does using a symbolic link require?







bash process






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 11 at 12:52









XavierStuvwXavierStuvw

3991828




3991828








  • 1





    I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

    – Rusi
    Mar 11 at 13:18














  • 1





    I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

    – Rusi
    Mar 11 at 13:18








1




1





I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

– Rusi
Mar 11 at 13:18





I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121

– Rusi
Mar 11 at 13:18










2 Answers
2






active

oldest

votes


















26














Don't use the name to kill it. Since the calling.sh script is calling the process you later want to kill, just use $! (from man bash):




!
Expands to the process ID of the job most recently placed
into the background, whether executed as an asynchronous command or using the bg builtin




So, if you're calling.sh is like this:



called.sh &
## do stuff
pkill called.sh


Change it to this:



called.sh &
calledPid=$!
# do stuff
kill "$calledPid"





share|improve this answer





















  • 4





    This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

    – Eugene Ryabtsev
    Mar 12 at 12:05






  • 2





    @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

    – terdon
    Mar 12 at 12:18











  • To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

    – XavierStuvw
    Mar 12 at 16:45



















18














I've had to pick this but out of scripts so many times; it's even more fun when the scripts are called as part of a complex automated schedule. You really shouldn't rely on something like pkill to select which script to kill.



Inside of calling.sh you should record the PIDs of the jobs you have started and kill them explicitly by PID.



Inside calling.sh:



./called.sh &
called_pid=$!

# Later
kill $called_pid





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%2f505629%2fbash-script-should-only-kill-those-instances-of-another-scripts-that-it-has-lau%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









    26














    Don't use the name to kill it. Since the calling.sh script is calling the process you later want to kill, just use $! (from man bash):




    !
    Expands to the process ID of the job most recently placed
    into the background, whether executed as an asynchronous command or using the bg builtin




    So, if you're calling.sh is like this:



    called.sh &
    ## do stuff
    pkill called.sh


    Change it to this:



    called.sh &
    calledPid=$!
    # do stuff
    kill "$calledPid"





    share|improve this answer





















    • 4





      This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

      – Eugene Ryabtsev
      Mar 12 at 12:05






    • 2





      @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

      – terdon
      Mar 12 at 12:18











    • To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

      – XavierStuvw
      Mar 12 at 16:45
















    26














    Don't use the name to kill it. Since the calling.sh script is calling the process you later want to kill, just use $! (from man bash):




    !
    Expands to the process ID of the job most recently placed
    into the background, whether executed as an asynchronous command or using the bg builtin




    So, if you're calling.sh is like this:



    called.sh &
    ## do stuff
    pkill called.sh


    Change it to this:



    called.sh &
    calledPid=$!
    # do stuff
    kill "$calledPid"





    share|improve this answer





















    • 4





      This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

      – Eugene Ryabtsev
      Mar 12 at 12:05






    • 2





      @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

      – terdon
      Mar 12 at 12:18











    • To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

      – XavierStuvw
      Mar 12 at 16:45














    26












    26








    26







    Don't use the name to kill it. Since the calling.sh script is calling the process you later want to kill, just use $! (from man bash):




    !
    Expands to the process ID of the job most recently placed
    into the background, whether executed as an asynchronous command or using the bg builtin




    So, if you're calling.sh is like this:



    called.sh &
    ## do stuff
    pkill called.sh


    Change it to this:



    called.sh &
    calledPid=$!
    # do stuff
    kill "$calledPid"





    share|improve this answer















    Don't use the name to kill it. Since the calling.sh script is calling the process you later want to kill, just use $! (from man bash):




    !
    Expands to the process ID of the job most recently placed
    into the background, whether executed as an asynchronous command or using the bg builtin




    So, if you're calling.sh is like this:



    called.sh &
    ## do stuff
    pkill called.sh


    Change it to this:



    called.sh &
    calledPid=$!
    # do stuff
    kill "$calledPid"






    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 11 at 14:54









    Toby Speight

    5,37611132




    5,37611132










    answered Mar 11 at 12:57









    terdonterdon

    132k32262441




    132k32262441








    • 4





      This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

      – Eugene Ryabtsev
      Mar 12 at 12:05






    • 2





      @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

      – terdon
      Mar 12 at 12:18











    • To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

      – XavierStuvw
      Mar 12 at 16:45














    • 4





      This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

      – Eugene Ryabtsev
      Mar 12 at 12:05






    • 2





      @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

      – terdon
      Mar 12 at 12:18











    • To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

      – XavierStuvw
      Mar 12 at 16:45








    4




    4





    This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

    – Eugene Ryabtsev
    Mar 12 at 12:05





    This should work as long as called.sh does not die by itself, because otherwise its pid might be reused, killing an innocent and unrelated process as a result.

    – Eugene Ryabtsev
    Mar 12 at 12:05




    2




    2





    @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

    – terdon
    Mar 12 at 12:18





    @EugeneRyabtsev that's a very good point. I guess you could also check that the $calledPid's parent PID is the PID of called.sh.

    – terdon
    Mar 12 at 12:18













    To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

    – XavierStuvw
    Mar 12 at 16:45





    To reinforce the answer, this is another resource I found useful to organize my thoughts: mywiki.wooledge.org/ProcessManagement

    – XavierStuvw
    Mar 12 at 16:45













    18














    I've had to pick this but out of scripts so many times; it's even more fun when the scripts are called as part of a complex automated schedule. You really shouldn't rely on something like pkill to select which script to kill.



    Inside of calling.sh you should record the PIDs of the jobs you have started and kill them explicitly by PID.



    Inside calling.sh:



    ./called.sh &
    called_pid=$!

    # Later
    kill $called_pid





    share|improve this answer






























      18














      I've had to pick this but out of scripts so many times; it's even more fun when the scripts are called as part of a complex automated schedule. You really shouldn't rely on something like pkill to select which script to kill.



      Inside of calling.sh you should record the PIDs of the jobs you have started and kill them explicitly by PID.



      Inside calling.sh:



      ./called.sh &
      called_pid=$!

      # Later
      kill $called_pid





      share|improve this answer




























        18












        18








        18







        I've had to pick this but out of scripts so many times; it's even more fun when the scripts are called as part of a complex automated schedule. You really shouldn't rely on something like pkill to select which script to kill.



        Inside of calling.sh you should record the PIDs of the jobs you have started and kill them explicitly by PID.



        Inside calling.sh:



        ./called.sh &
        called_pid=$!

        # Later
        kill $called_pid





        share|improve this answer















        I've had to pick this but out of scripts so many times; it's even more fun when the scripts are called as part of a complex automated schedule. You really shouldn't rely on something like pkill to select which script to kill.



        Inside of calling.sh you should record the PIDs of the jobs you have started and kill them explicitly by PID.



        Inside calling.sh:



        ./called.sh &
        called_pid=$!

        # Later
        kill $called_pid






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 11 at 13:04

























        answered Mar 11 at 12:59









        Philip CoulingPhilip Couling

        1,875920




        1,875920






























            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f505629%2fbash-script-should-only-kill-those-instances-of-another-scripts-that-it-has-lau%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?