Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.unix.xenix
Subject: Re: init's death solved (maybe)
Message-ID: <1989Jul7.000419.1700@eci386.uucp>
Date: 7 Jul 89 00:04:19 GMT
References: <1989Jul5.154102.703@tapa.uucp>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 42

In article <1989Jul5.154102.703@tapa.uucp> larry@tapa.uucp (Larry Pajakowski) writes:
>First thank's to all those who took the time to reply to my problems with init
>exiting.

Didn't notice what this thread was about before...

>Once an hour I run a script to disable and enable the tty port attached to the
>TB+ to take care of the port/modem going comotose.  Concurrent and unknown to
>me a getty was being re-spawned on tty11 every minute.  This is very similar
>to problems we and others have had with smart modems not configured correctly.

Xenix, at least in several older versions on multiple platforms has this
problem.  If you disable and then enable a port "too quickly", init can die.
Where "too quickly" depends....  This is even documented!   (in older
Xenix manuals at least).

"disable port" goes off and changes /etc/ttys (or /etc/inittab if you're
running the new init stuff), signal's /etc/init, and (I think) kills
any getty on that port.  /etc/init, on receipt of the signal, rescans
/etc/ttys (/etc/inittab), notes the changes, and then doesn't bother
to reissue the /etc/getty that died.

enable essentially diddles /etc/tty (/etc/init) and then signals /etc/init
to tell it to reread the file and restart the getty.

Now the rub - unless /etc/init has had a chance to run, rescan, and rearm 
the signal by the time the second signal comes in - it's bye-bye init.

I'm not too certain of the precise details of whether this is to do with
the problems with SV signaling in general, or just sloppiness in /etc/init.

Work around: put a "sleep 30" between disable and enable.  We used a version
of 4.3UUCP on a Xenix system that had this problem.  The UUCP had a mechanism
for turning the line around between incoming and outgoing.  Once we put
the sleep in, it never happened again.  (This was a *very* old version of
Xenix, but if this is the "generic" signal problem, it's probably still
there...)
-- 
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425