hedrick@geneva.rutgers.edu (Charles Hedrick) (01/14/89)
We just ran into a problem with telnetd under 4.0 that seems worth mentioning. Starting this morning, on two of our Sun 4's, any attempt to telnet to the system resulted in a hang. That is, telnet would say that the connection was open, but we wouldn't get the banner or the login: prompt. After a bit of debugging, I found that telnetd was hanging in an ioctl on the tty. The problem is that when you do an ioctl that changes terminal modes, and the process doing it is in the background, the process gets hung. The top-level process in telnetd meets all the tests for being in the background: it has a controlling terminal, and its process group is not the same as the process group of the terminal. (Telnetd sets its process group to 0, and the terminal also has a non-zero process group.) Thus all ioctl's (e.g. those done to set raw mode and echo) cause telnetd to hang. The cure is to put signal(SIGTTOU, SIG_IGN) fairly early in the code. This causes ioctl's not to hang. This problem completely mystifies me. I don't understand why the problem suddenly appeared, and only on some of our machines. Actually, if the diagnosis above is right, I don't understand why telnetd ever worked at all. As far as I can tell, the test for causing ioctl's to hang is the same in SunOS 3.2, SunOS 4.0, and BSD 4.3, and all of those versions of telnetd have code that would appear to trigger the problem. What am I missing? I should mention that we are not using an entirely standard telnetd. We do some magic near the beginning involving vhangup so that our users can't run jobs in the background that open pty's and read others' passwords.
cudcv%WARWICK.AC.UK@cunyvm.cuny.edu (Rob McMahon) (01/19/89)
hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >Starting this morning, on two of our Sun 4's, any attempt to telnet to the >system resulted in a hang. That is, telnet would say that the connection was >open, but we wouldn't get the banner or the login: prompt. I've seen this happen on our systems when somebody left a background process running on one of the pty's. If you're unlucky enough that the next free pty is the one with the process, telnet and rlogin will both successfully connect, but get no further. Killing the process, or modifying it to carefully close all files and dissociate itself from the terminal, will cure it. This could be why it's suddenly appeared, and is unpredictable. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England