18

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.

  • 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
16

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 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 Feb 22 at 21:47
  • @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 Feb 23 at 0:03
9

For me this works perfectly fine with disown

command & disown
2

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 : 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
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.