From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Description of problem:
Using hyperterm to connect to Linux box with 56K internal modem & mgetty
configured for ttyS4, abruptly disconnect the connection in the middle of a
task (ala cat a file or ls a directory) without logging out completely. The
mgetty dies (no longer shows up on ps) but the ttyS4 lock file remains. The
mgetty will never respawn, however, and subsequent attempts to dial into the
box will never be answered.
Version-Release number of selected component (if applicable):
Always / Sometimes
Steps to Reproduce:
1.spawn mgetty for internal modem
2.dial into box using hyperterm or other equivalent
3.run "cat" on a file or "ls" in a directory
4.abruptly disconnect the connection without logging out
5.redial box, phone line rings, no answer by mgetty
6.run ps on box, see that mgetty has not been respawned
7.check /var/lock dir & see that ttyS4 lock file is still present
Actual Results: modem placed into state where mgetty is never respawned and
will not answer line (even if lock file is removed).
Expected Results: modem cd loss would disable mgetty, cause lock file to be
removed, and mgetty respawned & answer subsequent calls to box when ringing.
One factor may involve phone line quality or modem / RS-232 signal detection re
CD + DTR? This problem has not been duplicated using a Black Box phone
simulator but very easily using other combinations of modems & phone lines.
mgetty.log entries state that the release is an "Experimental Version"
Unable to duplicate but leaving open since conditions often play a critical part
in such things
Closing out old bugs here.
I'm unable to duplicate this bug. If anyone can duplicate it with
current mgetty versions, please let me know how.
I experienced this bug too when using a cheap dual-RS232 card.
I've changed to a USB-RS232 adapter and now _this_ problem has gone away.
Now I'm stuck with Bug #167830.
Using vanilla FC5 system.