aabenson@balance.cs.mtu.edu (Andrew A. Benson) (04/23/91)
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. 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). Thanks, Andrew. Internet: aabenson@mtu.edu or aabenson@balance.cs.mtu.edu BITNET: AABENSON@MTUS5
jik@athena.mit.edu (Jonathan I. Kamens) (04/24/91)
In article <1991Apr23.144516.23119@news.miami.edu>, aabenson@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. You're right, it never gets the signal. Processes put into the background in csh do not get a HUP signal when the shell exits. |> 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). In order to find out if your parent process still exists, you call getppid() and see if the result is 1, i.e. the init process. When a process's parent exits, the process is inherited as a child by the init process. Therefore, if you are writing a program that is started in the background from csh and you need it to notice when its parent csh has died and clean up and exit, your program must periodically do getppid() and check the return value. If your program is started by another program under your control, rather than by csh, then you can create a pipe before the child is created; close the read end of the pipe in the parent and the write end of the pipe in the child; and then watch the pipe in the child to notice when it gets EOF (i.e. when the parent exits and the pipe is closed). You can watch the pipe either by using periodic select() or poll() calls on it to check if there is data waiting to be read (since that's how EOF is signalled), or by enabling asynchronous input on the pipe and the delivery of SIGIO, and installing a SIGIO handler to notice when the signal comes in. The former will work will if your program is already manipulating file descriptors using select() or poll(). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
s902255@minyos.xx.rmit.oz.au (Andrew Vanderstock) (04/24/91)
aabenson@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@mtu.edu or aabenson@balance.cs.mtu.edu > BITNET: AABENSON@MTUS5 -- Andrew Vanderstock s902255@minyos.xx.rmit.oz.au The opinions (if any) in this posting are not those of RMIT. They are all mine!
jik@athena.mit.edu (Jonathan I. Kamens) (04/25/91)
In article <1991Apr24.150154.19539@minyos.xx.rmit.oz.au>, s902255@minyos.xx.rmit.oz.au (Andrew Vanderstock) writes: |> Best way to ensure that all processes die when a user logs out is to |> alias logout to 'kill -1 -9'. Are you sure you don't mean 'kill -9 -1'. I don't know of any system that treats '-9' as a special PID, but I know '-1' works on many systems. And isn't it better to use 'kill -HUP -1'? If the original user was trying to guarantee that background processes got HUP signals, it seems silly me to use signals that are stronger than the HUP signal. Finally, note that, as far as I know, using that will guarantee a signal delivered to every process owned by the user *except* the process from which the signal was sent. If he's using a login shell with a built-in 'kill', this means that his login shell won't get the signal and he won't be logged out. You have to be careful about this. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710