Waiting on parents and reinstating HUP

Andrew Vanderstock s902255 at minyos.xx.rmit.oz.au
Thu Apr 25 01:01:54 AEST 1991


aabenson at balance.cs.mtu.edu (Andrew A. Benson) writes:

>Does anybody know how to set things up so a process started from csh
>with an & will die when the user logs out?  Is there something I need
>to do with SIGHUP signal handling?  I've tried everything I can think
>of.  My only other thought is that it just never ever gets the signal.

On our Sys V system, the processes sometimes hang, sometimes disappear.
Best way to ensure that all processes die when a user logs out is to
alias logout to 'kill -1 -9'. If you run daemons, maybe another method
should be found, as would be the case if you are into running multiple
sessions.

>My other question is if a process can check the status of its parent --
>to check to see if the parent still exists.  All the calls I've found
>only allow a process to check and/or wait on its children (the wait(),
>wait3(), wait4(), and waitpid() calls under SunOS 4.1).

You could open up some shared memory using shmop() or similar and talk
to each other? Other yukky hacks like this may do the trick better.
Signals also come into mind as being reasonable alternatives. Ah, yes
in my SysV manual (mileage may vary) it says that "the child process has
its own copy of the parent's file descriptors. Each of the child's file
descriptors shares a common file pointer with the corresponding file
descriptor of the parent." Maybe you can open a binary file as the parent,
and pass information in the form of a log, but I feel semaphores plus the
fact that you know your parent's pid should be enough, and safer in case
the parent dies or locks up.

>Thanks,

You got as much as I can help you.

>Andrew.

Hey you got my first name too! :-)

>Internet:     aabenson at mtu.edu  or  aabenson at balance.cs.mtu.edu
>  BITNET:     AABENSON at MTUS5

--
Andrew Vanderstock
s902255 at minyos.xx.rmit.oz.au

The opinions (if any) in this posting are not those of RMIT. They are all mine!



More information about the Comp.unix.programmer mailing list