Red Hat Bugzilla – Bug 55768
telnetd not providing controlling tty in session
Last modified: 2007-04-18 12:38:03 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) Description of problem: When I telnet into my redhat 7.1 system (with all the latest updates installed as of 2001-10-31) I randomly get a session with no controlling tty. It is running under a pty, it just doesn't make it the controlling tty for the session. The "tty" program can successfully report which pty, but the "ps" command shows ? as the controlling tty. Sometimes I'll have one and sometimes I won't. It isn't always the same pty with the problem. Both xterm and ssh sessions always appear to work properly, so the problem seems to be unique to the telnet daemon. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. telnet into linux from windows telnet client 2. run ps -fp $$ 3. run tty 4. See if tty says the same thing as the tty field of the ps output Actual Results: About 70% of the time, the ps tty info is ? instead of a pty name. Expected Results: The tty program and the ps output should always agree. Additional info: Most things work OK, but quite a lot of programs which want to prompt for passwords refuse to do so unless there is a controlling tty, so it is exceedingly annoying and sometimes difficult to work around.
can you please update util-linux and report if the problem still persists?
I was already running the latest util-linux, but I did an rpm upgrade with --force just to make sure (util-linux-2.11f-11.7.1.i386.rpm) and I still get the same results.
I am experiencing the same problem with our shell account server with 100% consistency. The problem only occurs with telnet (i.e., ssh works fine). I had the following versions installed (RH 7.1): util-linux-2.11f-11.7.1 telnet-server-0.17-18 As an experiment, I upgraded to telnet-server-0.17-20 from RH 7.2, but it did not solve the problem. If it would help, I can provide a user account on the server in question upon e-mail request.
Additional experimentation seems to suggest the problem might be related to, or affect only, tcsh. As an experiment, I changed my shell to bash, telnetted in, and received no warning, and had job control (i.e., I could suspend vi). Switching back to tcsh, the problem returned and, as expected, I couldn't suspend a vi session. Hopefully this helps some.
Tom, do you also have tcsh? Then this problem maybe is a tcsh problem?
Nope, my problems were all with bash. Another person at work has also tested his 7.1 system, and sees the same problem (I think with bash as well).
Bug Fix Advisory - RHBA-2001:153-06 ------------------------------------------------------------------------------ Summary: login fails to set controlling terminal Description: Due to terminal handling problems in /bin/login, tcsh would not find the controlling terminal correctly, and a shell in single user mode would exhibit strange terminal input characteristics. This update fixes both of these problems. ------------------------------------------------------------------------------ *** This bug has been marked as a duplicate of 54741 ***