Question Bash scripting.

[Linguofreak]

I'm using a bash script on my Linux machine to manage some helper programs for X-Plane (A joystick-to-keyboard program and a webcam head tracking program, at the moment). I basically want to start these programs up along with X-Plane, and then have them exit when X-Plane exits. So far, I've got something along the lines of:

program1 &
program2 &
X-Plane
killall -HUP program1 program2

Is there any better way than killall-ing each program by name to have both programs exit when X-Plane does? I've tried simply putting an exit statement in the script, but that doesn't seem to work.

 

[movieman]

I can't think of an obviously better option for the general case, but a lot of programs which are intended to run in the background have a command line option to write their pid to a file so you can later just read the file and use it to kill them.

 

[orb]

You can get PID from the last executed in the background process in BASH.
$! - Expands to the process ID of the most recently executed background (asynchronous) command.

program1 &
PID1=$!
program2 &
PID2=$!
X-Plane
kill -1 ${PID1} ${PID2}

(IIRC, HUP's code is 1.)

 

[movieman]

I thought there was some way like that to get the pid, but I couldn't remember what it was .

 

[Linguofreak]

You can get PID from the last executed in the background process in BASH.
$! - Expands to the process ID of the most recently executed background (asynchronous) command.

program1 &
PID1=$!
program2 &
PID2=$!
X-Plane
kill -1 ${PID1} ${PID2}

(IIRC, HUP's code is 1.)

OK, I was hoping for something that could kill everything associated with the shell instance running the script. Oh well.

Furthermore, is HUP a good signal to use? I know that there's some degree of suitability of different signals for different purposes: For example, KILL leaves no opportunity for cleanup and is thus generally to be reserved for misbehaving processes. But I don't know whether it's generally better to use HUP or INT. From the fact that you're not screaming "never, ever do that!" at me, I assume that it works well enough, but is it generally the best signal to use for the purpose in question?

 

[orb]

OK, I was hoping for something that could kill everything associated with the shell instance running the script. Oh well.

Ah, you wanted to kill every forked process that was executed by the script in background without knowing their PIDs? In this case I'd need to switch to my Linux installation to test the possibility, but I can't at the moment.

Shell should send SIGHUP to its child jobs if it received the HUP signal, i.e. "kill -HUP $$" should send SIGHUP to child processes ($$ is PID of shell running the script).

Furthermore, is HUP a good signal to use? I know that there's some degree of suitability of different signals for different purposes: For example, KILL leaves no opportunity for cleanup and is thus generally to be reserved for misbehaving processes. But I don't know whether it's generally better to use HUP or INT. From the fact that you're not screaming "never, ever do that!" at me, I assume that it works well enough, but is it generally the best signal to use for the purpose in question?

SIGINT is like you pressed Ctrl-C for a foreground process. In my opinion, SIGTERM is the proper signal for terminating a process, and if it doesn't want to terminate then like you said SIGKILL. I'm not sure for SIGHUP, but I rarely used it, only just to restart daemons.

 

[Linguofreak]

Ah, you wanted to kill every forked process that was executed by the script in background without knowing their PIDs? In this case I'd need to switch to my Linux installation to test the possibility, but I can't at the moment.

Shell should send SIGHUP to its child jobs if it received the HUP signal, i.e. "kill -HUP $$" should send SIGHUP to child processes ($$ is PID of shell running the script).

Interestingly, it works if run in a terminal (either interactively or as a script), but both processes survive if the script is run from the GUI without a terminal, regardless of the signal used.

SIGINT is like you pressed Ctrl-C for a foreground process. In my opinion, SIGTERM is the proper signal for terminating a process,

I guess my biggest question is whether there is any specific technical reason to use one signal versus another based on what happens when one or another is given (such as exactly how a process is terminated when it receives one signal or another).

I know, for example, how SIGKILL is processed differently from SIGTERM, SIGINT, or SIGHUP. I don't really know of any difference between the three except in their presumed origins. (Of course, this is just talking about default behavior. If a process is handling one of these on its own, there's no telling how that signal might be processed).

So is there any concrete difference between the three in the default processing of those signals, or is it pretty much a matter of convention?

 

[Wishbone]

The sending of a SIGHUP signal indirectly terminates children in some circumstances.

This is from my version of POSIX.

 

[movieman]

I know, for example, how SIGKILL is processed differently from SIGTERM, SIGINT, or SIGHUP.

The big difference is that SIGKILL is handled by the kernel, while the others are passed to the process. In the latter case they'll either be handled by the default signal handler(s), which may just exit, or by process-specific handlers which try to clean up.

Edit: Sorry, I thought you were saying you didn't know how they were processed . As you say, you can't really tell what the process is going to do when they receive the signal, in many cases SIGHUP is used to tell the process that it should re-read its configuration and doesn't really get used to indicate that the terminal has hung up. SIGTERM usually means the system is shutting down so the process should clean up and exit fast, whereas SIGINT means the user pressed CTRL+C so you should do any clean up required and exit when it's done.

 

[Linguofreak]

Edit: Sorry, I thought you were saying you didn't know how they were processed . As you say, you can't really tell what the process is going to do when they receive the signal, in many cases SIGHUP is used to tell the process that it should re-read its configuration and doesn't really get used to indicate that the terminal has hung up. SIGTERM usually means the system is shutting down so the process should clean up and exit fast, whereas SIGINT means the user pressed CTRL+C so you should do any clean up required and exit when it's done.

But assuming a process uses the default handler, is there any difference? I know the default action on all three is to quit, but is there any difference in how that is accomplished by the default handler between the three signals.