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 [EMAIL PROTECTED] Grace Lutheran Church (ELS) http://www.jvlnet.com/~jjacobsen/ Madison, Wisconsin GnuPG public key ID: 2E3EBF13