Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards Subject: Re: Sun child termination. Keywords: fork exec stdin Message-ID: <13602@mimsy.UUCP> Date: 18 Sep 88 08:54:08 GMT References: <347@intelisc.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 22 In article <347@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >On a Sun 3/50 running Sun OS 3.5 the [orphaned] child program terminates >with no message, at the read on stdin, as soon the parent terminates. If >the child does not read stdin, it survives. This happens only if the child's stdin is a tty and SIGTTIN is enabled (this is the default) and the process is started by a shell that understands job control. The child is in a separate process group, and its parent process is /etc/init (pid 1), since it has been orphaned. When it tries to read from a terminal, the tty driver code notices that it is not in the proper process group and sends a SIGTTIN (`stop on tty input') signal so that the ultimate parent shell can take note. Alas, there is no shell; the process is a child of init, and the signal code refuses to allow children of init to stop on keyboard signals, since no one is around to continue them. So the kernel translates the SIGTTIN to a SIGKILL, and kills the process. This is arguably the wrong thing to do, but then, there is not much that is arguably the *right* thing to do in such a situation. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris