home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.linux
- Path: sparky!uunet!haven.umd.edu!darwin.sura.net!gatech!cc.gatech.edu!news
- From: zundel@cc.gatech.edu (Eric Zundel Ayers)
- Subject: Serial port respawing problem
- Message-ID: <1993Jan25.181710.20588@cc.gatech.edu>
- Sender: news@cc.gatech.edu
- Reply-To: zundel@cc.gatech.edu (Eric Zundel Ayers)
- Organization: Georgia Institute of Technology
- Date: Mon, 25 Jan 1993 18:17:10 GMT
- Lines: 26
-
- I got some help with the getty "respawn" problem and a clearer explanation
- of what is going on with getty when you have a hard-wired serial line.
-
- BTW, I ran into the same problem again even with the -h flag set
- (I'm using 99pl2) but apparently this is fixed for good on 99pl4.
-
- ...(anonymous source, thanks for the help)...
-
- Close. What actually happens is that when getty starts up, it does a
- vhangup() to clean up any messes that the previous login left on the port
- --- and a kernel bug in vhangup() causes Linux to hang up the port and kill
- the getty. So another getty spawns, and around and around we go :-)
-
- The 0.99pl4 kernel fixes this. The "-h" (don't vhangup()) option to getty
- works around this, but if the previous login session left anything running
- in the background with output to the tty, things can get messy. (If you
- have "stty -tostop", that is. With "stty tostop" the mess-making program
- gets killed instead. Or at least it should. I hope vhangup() isn't what
- arranges for this... if it is, such a program will be hung until the next
- reboot.)
-
-
- Eric Z. Ayers
- zundel@cc.gatech.edu
- Graphics, Visualization, and Usability Center (GVU)
- Georgia Institute of Technology, Atlanta, GA 30213 USA
-