How can I detach a process from a bash script?
I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.
I have used the disown
command in terminal directly, however in bash, disown
does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.
In terminal it would look something like this:
$ openocd & # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB
when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.
Any help would be greatly appreciated.
ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.
bash disown
add a comment |
I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.
I have used the disown
command in terminal directly, however in bash, disown
does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.
In terminal it would look something like this:
$ openocd & # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB
when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.
Any help would be greatly appreciated.
ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.
bash disown
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.
– Bruce Ediger
Mar 15 '16 at 0:38
1
Are you open to using a tool likescreen
?
– Eric Renouf
Mar 15 '16 at 2:52
add a comment |
I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.
I have used the disown
command in terminal directly, however in bash, disown
does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.
In terminal it would look something like this:
$ openocd & # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB
when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.
Any help would be greatly appreciated.
ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.
bash disown
I am trying to detach a process from a bash script so that SIGINT will not be forwarded to the process when I exit the script.
I have used the disown
command in terminal directly, however in bash, disown
does not stop SIGINT from being forwarded. The purpose of this script is to start openocd and then gdb with a single invocation. Since the script never exits (it's running gdb) SIGINT is still forwarded from gdb to openocd which is a problem since SIGINT is used as the halt command in gdb.
In terminal it would look something like this:
$ openocd & # run openocd demonized
$ disown $! # disown last pid
$ gdb # invoke GDB
when invoked on terminal in this order, the SIGINT is not passed from gdb to openocd. However if this same invocation was in a bash script, the SIGINT is passed.
Any help would be greatly appreciated.
ps this problem is in OS X but I am trying to use tools which are also portable to all Unix tools.
bash disown
bash disown
edited Mar 15 '16 at 2:10
user2328113
asked Mar 14 '16 at 23:39
user2328113user2328113
84115
84115
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.
– Bruce Ediger
Mar 15 '16 at 0:38
1
Are you open to using a tool likescreen
?
– Eric Renouf
Mar 15 '16 at 2:52
add a comment |
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.
– Bruce Ediger
Mar 15 '16 at 0:38
1
Are you open to using a tool likescreen
?
– Eric Renouf
Mar 15 '16 at 2:52
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.– Bruce Ediger
Mar 15 '16 at 0:38
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.– Bruce Ediger
Mar 15 '16 at 0:38
1
1
Are you open to using a tool like
screen
?– Eric Renouf
Mar 15 '16 at 2:52
Are you open to using a tool like
screen
?– Eric Renouf
Mar 15 '16 at 2:52
add a comment |
4 Answers
4
active
oldest
votes
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out
.
If you wish to execute a detached command while being able to see the output in the terminal, then use tail
:
TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &
Why isnohup
necassary? What is the difference betweennohup COMMAND &
andCOMMAND &
if your goal is only to run command in background and free the terminal?
– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
add a comment |
For me this works perfectly fine with disown
command & disown
add a comment |
a simple and portable solution :
echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
echo "openocd is running with pid: $pid"
gdb
Some portability caveats: ps
options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1
. at
could not be available (weird, but this happens...). $(...)
needs a not reallllly old shell, otherwise use backticks.
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : haveat
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.
– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
add a comment |
The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website
Once compiled, it can be used in a script as follows:
$ ./detach -p debug.pid openocd <args> # detach openocd
$ gdb <args> # run gdb
$ kill -9 $(cat debug.pid) # end openocd process
$ rm debug.pid # remove file containing process id
This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.
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%2f269805%2fhow-can-i-detach-a-process-from-a-bash-script%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out
.
If you wish to execute a detached command while being able to see the output in the terminal, then use tail
:
TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &
Why isnohup
necassary? What is the difference betweennohup COMMAND &
andCOMMAND &
if your goal is only to run command in background and free the terminal?
– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
add a comment |
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out
.
If you wish to execute a detached command while being able to see the output in the terminal, then use tail
:
TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &
Why isnohup
necassary? What is the difference betweennohup COMMAND &
andCOMMAND &
if your goal is only to run command in background and free the terminal?
– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
add a comment |
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out
.
If you wish to execute a detached command while being able to see the output in the terminal, then use tail
:
TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &
To detach a process from a bash script:
nohup ./process &
If you stop your bash script with SIGINT, or the shell exits sending SIGHUP for instance, the process won't be bothered and will continue to execute normally. stdout & stderr will be redirected to a log file: nohup.out
.
If you wish to execute a detached command while being able to see the output in the terminal, then use tail
:
TEMP_LOG_FILE=tmp.log
> "$TEMP_LOG_FILE"
nohup ./process &> "$TEMP_LOG_FILE" & tail -f "$TEMP_LOG_FILE" &
edited 1 hour ago
answered Mar 15 '16 at 10:50
marcmarc
1,5881520
1,5881520
Why isnohup
necassary? What is the difference betweennohup COMMAND &
andCOMMAND &
if your goal is only to run command in background and free the terminal?
– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
add a comment |
Why isnohup
necassary? What is the difference betweennohup COMMAND &
andCOMMAND &
if your goal is only to run command in background and free the terminal?
– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
Why is
nohup
necassary? What is the difference between nohup COMMAND &
and COMMAND &
if your goal is only to run command in background and free the terminal?– James Wierzba
4 hours ago
Why is
nohup
necassary? What is the difference between nohup COMMAND &
and COMMAND &
if your goal is only to run command in background and free the terminal?– James Wierzba
4 hours ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
@JamesWierzba One among the differences is that if you need the command to continue to run even after exiting the shell, then nohup is the way to go. There are thousand of extensive explanations in the web. E.g. stackoverflow.com/questions/15595374/…
– marc
1 hour ago
add a comment |
For me this works perfectly fine with disown
command & disown
add a comment |
For me this works perfectly fine with disown
command & disown
add a comment |
For me this works perfectly fine with disown
command & disown
For me this works perfectly fine with disown
command & disown
answered May 5 '17 at 12:05
ManuelSchneid3rManuelSchneid3r
1,74372246
1,74372246
add a comment |
add a comment |
a simple and portable solution :
echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
echo "openocd is running with pid: $pid"
gdb
Some portability caveats: ps
options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1
. at
could not be available (weird, but this happens...). $(...)
needs a not reallllly old shell, otherwise use backticks.
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : haveat
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.
– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
add a comment |
a simple and portable solution :
echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
echo "openocd is running with pid: $pid"
gdb
Some portability caveats: ps
options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1
. at
could not be available (weird, but this happens...). $(...)
needs a not reallllly old shell, otherwise use backticks.
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : haveat
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.
– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
add a comment |
a simple and portable solution :
echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
echo "openocd is running with pid: $pid"
gdb
Some portability caveats: ps
options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1
. at
could not be available (weird, but this happens...). $(...)
needs a not reallllly old shell, otherwise use backticks.
a simple and portable solution :
echo "openocd" | at now #openocd starts now, but via the at daemon, not the current shell!
pid=$(ps -ef | grep "[o]penocd" | awk '{print $1}')
echo "openocd is running with pid: $pid"
gdb
Some portability caveats: ps
options depends on the OS! you could instead use a variant of : { ps -ef || ps aux ;} | grep '[o]penocd | cut -f 1
. at
could not be available (weird, but this happens...). $(...)
needs a not reallllly old shell, otherwise use backticks.
edited Mar 15 '16 at 5:15
answered Mar 15 '16 at 5:03
Olivier DulacOlivier Dulac
3,8331325
3,8331325
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : haveat
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.
– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
add a comment |
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : haveat
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.
– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
This seems dangerous, grepping for pid may do unexpected things if more than one process is running with the same name, or even, if another process contains the word openocd.
– orion
Mar 15 '16 at 8:06
1
1
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have
at
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.– Olivier Dulac
Mar 15 '16 at 9:21
@orion: i give a simple example to give the ideas, those concerns you mention are easy to get rid of : have
at
start a script that launches the program and gives out its pid instead in a file, and have the main script wait for that file to appear and then read the pid from it.– Olivier Dulac
Mar 15 '16 at 9:21
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
of course you should replace in my (overly simple) example the grep with a test inside awk, on the right column ($8, usually)(the columns depends on your os and version/options of ps)
– Olivier Dulac
Mar 15 '16 at 10:42
add a comment |
The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website
Once compiled, it can be used in a script as follows:
$ ./detach -p debug.pid openocd <args> # detach openocd
$ gdb <args> # run gdb
$ kill -9 $(cat debug.pid) # end openocd process
$ rm debug.pid # remove file containing process id
This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.
add a comment |
The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website
Once compiled, it can be used in a script as follows:
$ ./detach -p debug.pid openocd <args> # detach openocd
$ gdb <args> # run gdb
$ kill -9 $(cat debug.pid) # end openocd process
$ rm debug.pid # remove file containing process id
This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.
add a comment |
The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website
Once compiled, it can be used in a script as follows:
$ ./detach -p debug.pid openocd <args> # detach openocd
$ gdb <args> # run gdb
$ kill -9 $(cat debug.pid) # end openocd process
$ rm debug.pid # remove file containing process id
This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.
The solution I found involves a program called 'detach' written by Annon Inglorion and downloadable from his website
Once compiled, it can be used in a script as follows:
$ ./detach -p debug.pid openocd <args> # detach openocd
$ gdb <args> # run gdb
$ kill -9 $(cat debug.pid) # end openocd process
$ rm debug.pid # remove file containing process id
This first line creates a new process (running openocd) and stores the process id in file (debug.pid) for use later. This prevents the issues with grepping for the pid as provided in Oliver's answer. Upon exiting the next blocking program (gdb) the file storing the pid is used to kill the detached process directly.
answered May 4 '17 at 18:11
user2328113user2328113
84115
84115
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%2f269805%2fhow-can-i-detach-a-process-from-a-bash-script%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
nohup
isn't quite the right answer. You should add some pseudocode or example code to show more precisely what you want.– Bruce Ediger
Mar 15 '16 at 0:38
1
Are you open to using a tool like
screen
?– Eric Renouf
Mar 15 '16 at 2:52