Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!sri-unix!hplabs!hpcea!hpda!hppcgo!hpisoa2!hpisod1!hpisoa1!davel From: davel@hpisoa1.HP.COM (Dave Lennert) Newsgroups: comp.unix.wizards Subject: Re: stopped jobs don't always disappear (after logout) Message-ID: <2200004@hpisoa1.HP.COM> Date: Mon, 24-Nov-86 00:39:53 EST Article-I.D.: hpisoa1.2200004 Posted: Mon Nov 24 00:39:53 1986 Date-Received: Wed, 26-Nov-86 20:47:58 EST References: <4060005@csd2.UUCP> Lines: 30 > Most UNIX kernels that support job control have a provision > for cleaning up stopped jobs when the user insists on logging > out without taking care of them. 4.2 does this within exit() > by checking if any of the exit'er's children have been suspended. > If so, it sends each such child a SIGHUP followed by a SIGCONT. > > A problem occurs in cases when programs fork/exec with the > parent ignoring SIGHUP during its wait(). If this job is suspended, > peculiar things happen when the user logs out. When the login > shell exits, the kernel notices the stopped child and sends it a > SIGHUP which is ignored. The subsequent SIGCONT simply changes the > process state from stopped to wait/blocked. The child's child is never > sent any signal. This results in both processes hanging around with > the parent blocked and waiting for a child which is suspended. You're right. Exit() should probably send SIGHUP & SIGCONT to the entire process group rather than just the immediate stopped children. However, if some children (other processes in the process group) were not currently stopped, this would kill them unexpectedly. (Remember that in 4.2 based systems, SIGHUP is usually sent to only *some* processes when a user logsoff.) The bottom line is: If a process ignores SIGHUP, it better know what it's doing. Dave Lennert ucbvax!hpda!davel [UUCP] Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP] 19447 Pruneridge Ave. Cupertino, CA 95014 (408) 447-6325 [AT&T]