SUMMARY: Getty waiting on a socket

From: Jay Plett (jay@silence.princeton.nj.us)
Date: Sun Jan 26 1992 - 05:10:21 CST


Actually, this is an interim report more than a summary. I
asked about dialin/out modem lines with their getty blocked on
rsockt, which doesn't make sense.

First, a workaround furnished by robert@gar.no (Robert Andersson):
simply add "to#60" to the gettytab entry used by the modems.
The offending getty will timeout after 60 seconds, exit, and
init will produce a fresh getty without the problem. While this
does not address the underlying problem, it does prevent the
dialin lines from becoming permanently disabled and keeps one's
shop in working order. If you have Telebit T2500 modems (and
perhaps others) on dialin/out modem lines on a Sun, you should
do this.

Here is what is happening. getty thinks that it has the modem
line open. It proceeds to dup it a couple of times, so that
file descriptors 0, 1 & 2 will be open on the modem. It goes on
to condition the line with several ioctl's. It doesn't bother
to check the return values of the dup's, but it does check on
the ioctl's. The hitch is that the line is *not* open. The
dup's fail without notice. When the ioctl's fail (because they
are handed an invalid file descriptor), getty reports the
failures via syslog. syslog opens a socket to log the errors.
This open returns 0, the first available fd! The ioctl failures
are logged, but getty proceeds anyway. Satisfied that all is in
order, getty does a read on fd 0 to get a login name. But fd 0
is the socket that syslog opened, not the modem. Of course,
there is never any input on this file descriptor, so getty waits
forever. What remains to be explained is how getty gets itself
into this embarassing position.

I will continue trying to get to the bottom of this. Meanwhile,
if anybody has anything to contribute, please speak up!

        ...jay



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:35 CDT