Why no SIGPARENT in UNIX?
Chris Handorf
whenever of its child processes terminates. Why is there no corresponding
SIGPARENT signal that notifies a child process if the parent process
terminates?
Instead, UNIX conveniently sets the parent process id of the child process
to 1 without notifying the child process. I would like the child process
to terminate instead.
If the parent process calls fork(), and then wait() and the child process
calls sleep(99999), a "kill -9" command to the parent process WILL
automatically kill the child process. Unfortunately this approach means
that the parent process can do NOTHING until the child process exits.
If instead the parent process does not call wait() but continues to do
something else, a "kill -9" to the parent will NOT kill the child process
also.
So, how does a UNIX/C programmer start a child process with fork()/exec()
and INSURE that if the parent process dies the child process is taken with
it?
There are many cases where this is useful such as killing an xterm should
kill the shell contained within the term, killing a shell should kill a
sleep command typed into that shell, etc.
In my situation the child process is /usr/bin/remsh hostname -n
my_x_program. If I kill the process that started the remsh I would like
my_x_program running on the remote host to terminate.
Any help would be great!
If possible email responses to chris_...@email.sps.mot.com
Chris
Peter Mutsaers
>> (Chris Handorf) said:
CH> In UNIX there is a SIGCHLD signal that notifies a "parent"
CH> process whenever of its child processes terminates. Why is
CH> there no corresponding SIGPARENT signal that notifies a child
CH> process if the parent process terminates?
CH> Instead, UNIX conveniently sets the parent process id of the
CH> child process to 1 without notifying the child process. I would
CH> like the child process to terminate instead.
CH> So, how does a UNIX/C programmer start a child process with
CH> fork()/exec() and INSURE that if the parent process dies the
CH> child process is taken with it?
When a child is created it belongs to the same process group as the
parent. If the process group *leader* dies, all processes in the
process group receive the signal SIGHUP. The default action for this
signal is to terminate.
So you must take care only that your parent process is the process
group leader (setpgrp(2) or setsid(2)) and what you want will happen
(unless the child changes the SIGHUP action).
--
Peter Mutsaers | AT Computing bv, P.O. Box 1428,
p...@atcmp.nl | 6501 BK Nijmegen, The Netherlands
tel. work: +31 (0)80 527248 |
tel. home: +31 (0)3405 71093 | "... En..., doet ie het al?"
Garrett Jost
>When a child is created it belongs to the same process group as the
>parent. If the process group *leader* dies, all processes in the
>process group receive the signal SIGHUP. The default action for this
>signal is to terminate.
>So you must take care only that your parent process is the process
>group leader (setpgrp(2) or setsid(2)) and what you want will happen
>(unless the child changes the SIGHUP action).
In SVR4, I don't believe that is true. The session group leader must
die for any SIGHUPs to be sent. And SIGHUPs will only be sent to the
forground process group.
For this to work, the parent processes would have to call setsid(2) before
creating the child. You also have to make sure that the parent is not a
process group leader before this call, either, or else it will fail. It will
also disconnect you from your controlling terminal (the whole point of the
call).
So if you didn't mind not having the original controlling terminal for
this program, this method would work. The parent would be the session
and forground process group leader, and the child would receive a SIGHUP
when the parent died.
--
Garrett Jost grj...@oes.amdahl.com
Amdahl Corp. (No, we are NOT the company that makes clone x86 chips!)
[ These are my opinions and do not represent the opinions of my employer. ]