Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site lsrhs.UUCP
Path: utzoo!linus!decvax!genrad!grkermi!lsrhs!smiles
From: smiles@lsrhs.UUCP (Kevin "Mr. Boots" Ruddy)
Newsgroups: net.bugs.2bsd
Subject: init
Message-ID: <810@lsrhs.UUCP>
Date: Mon, 6-Jan-86 15:56:19 EST
Article-I.D.: lsrhs.810
Posted: Mon Jan  6 15:56:19 1986
Date-Received: Tue, 7-Jan-86 06:56:51 EST
Expires: Thu, 6-Feb-86 00:00:00 EST
Reply-To: smiles@lsrhs.UUCP (Kevin "Mr. Boots" Ruddy)
Distribution: net
Organization: LSRHS, Sudbury MA
Lines: 26
Keywords: init
Co-Author: texas@lsrhs.UUCP (Mike "Better Than Most Imported Beers" Shanzer)

There is apparently a very interesting (and annoying) bug in 2.9's init, or
so we have encountered.  If ^C is hit in between when init forks and when
getty is exec'd, SIGINT is sent to init.  Sometimes this even happened to
running login's.

This bug should be able to be reproduced by repeatedly hitting ^C at any
currently running getty or login.  The result of this is that init's child
thinks it's going into special session.  It logs everyone out and is a
rather nasty problem.  (A question: when this happens, it sometimes happens
that not everyone is logged out.  Why would kill(-1, SIGKILL) not always
work?)

The best fix for this would be this: after init forks in dfork(), have
it firstly setpgrp(0, getpid()).  This should solve all problems.  For
some odd reason, when we do this, and compile -ljobs, init "breaks" and
things go temporarily haywire, and it becomes impossible to log in.
Our second solution was to signal(SIGINT, SIG_DFL), rather than setpgrp().
This seems to have fixed the problem.

Has anyone else experienced this problem?  It became very annoying when
we started to use the 'B' option in getty, and people tried to set speeds
by hitting ^C many times in a row ...
--
ADDR: Kevin Ruddy, 42 Pantry Road, Sudbury MA  01776
UUCP: {genrad!grkermit,harvard!wjh12,bbncca,mit-eddie!frog}!lsrhs!smiles
ARPA: lsrhs!smiles@bbncca.arpa