Bash script should only kill those instances of another script's that it has launched
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
add a comment |
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
1
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
Mar 11 at 13:18
add a comment |
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
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
bash process
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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 thebg
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"
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 ofcalled.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
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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 thebg
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"
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 ofcalled.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
add a comment |
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 thebg
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"
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 ofcalled.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
add a comment |
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 thebg
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"
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 thebg
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"
edited Mar 11 at 14:54
Toby Speight
5,37611132
5,37611132
answered Mar 11 at 12:57
terdon♦terdon
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 ofcalled.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
add a comment |
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 ofcalled.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
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Mar 11 at 13:04
answered Mar 11 at 12:59
Philip CoulingPhilip Couling
1,875920
1,875920
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
Mar 11 at 13:18