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
14 hours ago
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 15 hours ago
XavierStuvwXavierStuvw
3711826
3711826
1
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
14 hours ago
add a comment |
1
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
14 hours ago
1
1
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
14 hours ago
I believe unshare is specifically for this: unix.stackexchange.com/a/450242/323121
– Rusi
14 hours ago
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"
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"
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"
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 13 hours ago
Toby Speight
5,34811031
5,34811031
answered 15 hours ago
terdon♦terdon
132k32260441
132k32260441
add a comment |
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 15 hours ago
answered 15 hours ago
Philip CoulingPhilip Couling
1,704920
1,704920
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
14 hours ago