Bug 55768 - telnetd not providing controlling tty in session
telnetd not providing controlling tty in session
Status: CLOSED DUPLICATE of bug 54741
Product: Red Hat Linux
Classification: Retired
Component: telnet (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2001-11-06 08:13 EST by Tom Horsley
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-09 13:27:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2001-11-06 08:13:35 EST
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:

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.
Comment 1 Harald Hoyer 2001-11-06 08:19:06 EST
can you please update util-linux and report if the problem still persists?
Comment 2 Tom Horsley 2001-11-06 18:58:38 EST
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.
Comment 3 Andrew Turnquist 2001-11-08 12:08:29 EST
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):

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.
Comment 4 Andrew Turnquist 2001-11-08 16:36:51 EST
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.
Comment 5 Harald Hoyer 2001-11-09 05:15:27 EST
Tom, do you also have tcsh? Then this problem maybe is a tcsh problem?
Comment 6 Tom Horsley 2001-11-09 13:27:53 EST
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).
Comment 7 Harald Hoyer 2001-12-13 08:41:31 EST
Bug Fix Advisory - RHBA-2001:153-06
login fails to set controlling terminal

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 ***

Note You need to log in before you can comment on or make changes to this bug.