Too many inits

Steven M. Kramer smk at linus.UUCP
Sun Jun 5 08:43:01 AEST 1983


Surprise!  This is NOT a flame.  This applies to 4.1bsd:

init appears on each terminal that is modem-controlled and the carrier
has not yet been established.  The associated terminal is ? since in
the open routines for the device, the controlling tty is determined AFTER
the hardware open is done.

For the direct connects, the carrier is always established, init does
its work, and then calls getty.  getty then proceeds until it
outputs login: and does a read for the login name (which it will pass
to login as an arg.  

That's why when using modem-controlled lines, the login: appears automatically
after you connect, and why on direct connects, you have to hit return to
see login:  (because it already did that and is now waiting for your
name).  With direct connects, since it's waiting for input, you can
just type your name as long as no garbage was produced after you turned
your terminal on.

We needed to know this cause we put a timeout feature into both login and getty.
We could only do this to modem-controlled lines, because the direct
ones would timeout and start another init-getty, timeout ...
The modem lines would start init and wait on the open.  The former wastes
much cpu time and process #'s especially for low timeout periods, and the
latter is more like what we wanted.  We were mainly concerned about
people calling up, going out for coffee, and leaving a shared line (crucial
to us) open.

Also, uucp administrators should know this behavior for the sites they call.
If hardwired to modems (such lines are stupid, prone to security attack,
but they exist out there), put in an extra "" "" in the L.sys line, otherwise
use the std login: or gin--gin stuff directly.  When I connect to a site
for the first time, I use cu to find out what type of line behavior it is
on the other end and set up accordingly.  This is better than having
uucp timeout if the original login: doesn't appear (at today's phone costs,
no wonder Bell encourages such hookups).

	--steve



More information about the Comp.unix.wizards mailing list