potato: mgetty and strange new behavior at startup
I'm using mgetty on a modem so I can call in from elsewhere. I also
have pppd set up to use the same modem to dial out. This arrangement
was working quite well for a long time. Now at startup, mgetty is not
releasing the modem, and if I kill it, init restarts it with the same
behavior.
The problem seems to be that exactly described in the mgetty info page
for BSD systems. Quoting:
I think it works quite well, except that the `VTIME' mechanism to
timeout `read()' calls doesn't work in older *BSD versions. If
`mgetty' hangs, with the last line in the log file being something
like "waiting for line to clear", upgrade your kernel, or, if you
can't do that, compile `mgetty' with `-DBROKEN_VTIME' (in that case,
select() will be used).
I get this impression from the log file, which says:
03/19 07:02:23 yS2 mgetty: experimental test release 1.1.21-Jul24
03/19 07:02:23 yS2 check for lockfiles
03/19 07:02:23 yS2 checklock: stat failed, no file
03/19 07:02:23 yS2 locking the line
03/19 07:02:23 yS2 makelock(ttyS2) called
03/19 07:02:23 yS2 do_makelock: lock='/var/lock/LCK..ttyS2'
03/19 07:02:23 yS2 lock made
03/19 07:02:24 yS2 tio_get_rs232_lines: status: RTS CTS DSR DTR RI
03/19 07:02:24 yS2 lowering DTR to reset Modem
03/19 07:02:24 yS2 tss: set speed to 38400 (017)
03/19 07:02:24 yS2 tio_set_flow_control( HARD )
03/19 07:02:24 yS2 waiting for line to clear (VTIME), read:
I say this behavior occurs at startup because the last time I started
up (about a week or more ago) I manually removed the inittab entry for
mgetty, locked ttyS2, reinserted the inittab entry, and once ttyS2 was
unlocked, mgetty behaved normally. Maybe this was a fluke.
The only think I can think of is that mgetty's using a depreciated
/proc interface that I didn't compile compatibility for in my latest
kernel.
Other ideas? Solutions?
--
Jesse Jacobsen, Pastor jjacobsen@jvlnet.com
Grace Lutheran Church (ELS) http://www.jvlnet.com/~jjacobsen/
Madison, Wisconsin GnuPG public key ID: 2E3EBF13
Reply to: