Signals/Parent/child process

Signals/Parent/child process

Post by -Sallstrom,C. » Fri, 26 Mar 1999 04:00:00



I am experimenting with some various pieces of code and several
books but am seeing a problem that I dont quite understand fully
yet.

I have a process that forks, where both parent/child acquire access
to some share memory and upon a Ctl-C catch the signals and update
this shared memory.  The parent updates the memory from within the
signal handler correctly, and I see the signal handler being called
for the child but it just up and falls of the face of the earth
during the call, as I presume the parent dies and takes its kid
with it.  How does one make sure the entire signal handler run
for the child or am I doing something totally wrong.

Thankx:

        Chris Sallstrom

 
 
 

Signals/Parent/child process

Post by James Maur » Sat, 27 Mar 1999 04:00:00


You installed a handler for SIGINT (^c) - which has a default
disposition  of causing the process to exit.

Did you use a reliable interface to install the handler?
If you used signal(3C), it will reset the default disposition
when the signal is delivered, so the second ^c would
cause the parent to exit.

Use sigaction().

/jim


>I am experimenting with some various pieces of code and several
>books but am seeing a problem that I dont quite understand fully
>yet.

>I have a process that forks, where both parent/child acquire access
>to some share memory and upon a Ctl-C catch the signals and update
>this shared memory.  The parent updates the memory from within the
>signal handler correctly, and I see the signal handler being called
>for the child but it just up and falls of the face of the earth
>during the call, as I presume the parent dies and takes its kid
>with it.  How does one make sure the entire signal handler run
>for the child or am I doing something totally wrong.

>Thankx:

> Chris Sallstrom



 
 
 

1. Signals from child process can't interrupt wait() from parent?

Hi -

   I have a really weird thing happening, and it LOOKS like what happens
is that when the parent (who is wait()ing on it's child) catches a
signal issued by that child process, the wait() is NOT interrupted.  This
is happening on Solaris 2.6.  Is this correct behavior?

   Here's the background:

   I've got a nifty RPC server routine which the client can kick-start if
it's not already there.  The idea is that the client will just wait for the
server to initialize, and then contact it.  So the client fork()s and
then execl()s the server process.  The server process fork()s off
the child to do the real work, then is supposed to hang around until the
child is initialized (ie, gets past the svc_create() successfully).  This
way, when the client's wait() completes with a 0 status, it knows the
server is ready for it.

   The simple solution seemed to be to have the parent schedule an alarm()
for itself just before the fork() and then wait() just after the fork().
If the child exits for other reasons, the wait() returns the pid; if the
wait() gets interrupted by SIGHUP, or SIGALRM (the latter if the server
never responded or exited), then wait() should return -1 and set errno to
EINTR.

   Yet, in practice, the server receives the SIGHUP (and prints a debug
message to that effect), then goes on wait()ing until the SIGALRM, at which
point the wait() returns -1 and sets errno to EINTR.

   While it's wait()ing, I *can* send a SIGHUP (-1) to the server process
from another shell and the wait() will be interrupted, but, somehow,
this doesn't work if the SIGHUP is coming from the child!

   Is this the correct behavior?  Is there something the signal handler
should do to break the wait()?  The signal handler DOES report receipt of
the SIGHUP, so I know the signal is being delivered correctly.

   As I'm writing this, it occurs to me that I can just put a signal handler
in for SIGCHLD, stuff the wait() into it and use pause() to wait for any
of the three expected signals.  But my curiosity remains, how/why is wait()
ignoring signals from the child, or what is really going on?

   My platform is a Sun UltraSPARC 30 running Solaris 2.6.

                                Thanks for your time,

                                        Mario

2. Keyboardproblems with 1.3.4

3. signals: stop child, parent told child died !

4. Newbie stuck with XServer problem running XApp-enabled servlets

5. Can a child process change the parent process's directory?

6. Bugs sitting in the RESOLVED state for more than 2 weeks

7. child process of parent process group

8. How to remove pseudo tty with no process????

9. Parent process also terminating after killing child process in SIGINT

10. How does a parent process know his child process dead?

11. how does a parent process know his child process dead?

12. How can kill all child processes without killing parent process ?