Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: non-job-control sh (was: Re: System V Release 4.0 Developers)
Message-ID: <14119@mimsy.UUCP>
Date: 23 Oct 88 01:01:06 GMT
References: <8658@smoke.ARPA> <216100004@s.cs.uiuc.edu> <7610@bloom-beacon.MIT.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <7610@bloom-beacon.MIT.EDU> scs@athena.mit.edu (Steve Summit)
writes [context: 4BSD]:
>The only real problem is when you're using an old shell as a
>login shell, but you're using the new tty line discipline, with a
>suspend character enabled.  As I recall, ^Z then logs you out,

It does, but:

>because init regains control when the shell is suspended, and it
>is not ready, willing, or able to do job control for you.  (The
>fact that you get logged out rather than zombieified may require
>some special handling on init's part.)

in fact it is much worse.  init does nothing about stopped processes,
and so the kernel takes it upon itself to translate `keyboard stop'
signals (SIGTSTP, SIGTTIN, and SIGTTOU) into SIGKILL when those signals
are being delivered to a child of init and the action is the default
(see psignal() in /sys/sys/kern_sig.c).

Why this was done rather than having init itself kill (or---for
SIGTSTP---continue) such processes I do not know.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris