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