Too many inits
chris.umcp-cs%udel-relay at sri-unix.UUCP
chris.umcp-cs%udel-relay at sri-unix.UUCP
Mon Jun 6 22:04:30 AEST 1983
From: Chris Torek <chris.umcp-cs at udel-relay>
From: harpo!eagle!mit-vax!mit-eddi!genrad!linus!smk at ucb-vax
... cause we put a timeout feature into both login and
getty.
I thought 4.1bsd login had a timeout. O well, maybe we put it
locally.
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.
That's what we've got: only auto-bauding lines (and all our dialups
are auto-bauding lines) time out.
Also, uucp administrators should know this behavior for
the sites they call.
It's probably best to ask someone at the site you're calling, rather
than just dialing up the line and trying something. Often what
works fine for someone using a modem doesn't work quite right for
uucp, because of silly things like uucp sending newlines, not
carriage returns. Our auto-baud code (in getty) only recognizes
carriage returns; if you called us up and hit return you'd get the
login prompt, and then perhaps assume that one "" "" entry in L.sys
will work.
Uucp administrators should also know about the -x option to uucico.
If you're having trouble dialing a site, you can run
/usr/lib/uucp/uucico -r1 -s<system> -x<debug-level> &
(where <system> is the name of the site, and <debug-level> is a
single digit between 1 and 9) and watch what happens. Debug levels
6 (I think) to 9 show what's going on during those L.sys entries,
so you can see what you're getting back from the remote system.
Very handy for tracking down noise problems, or if the other end
is at the wrong baud rate, etc. But you should warn the other site
you're doing this; it makes a debug log on their end, which they
may want to clean out afterwards.
- Chris
More information about the Comp.unix.wizards
mailing list