Bug 55768

Summary:	telnetd not providing controlling tty in session
Product:	[Retired] Red Hat Linux	Reporter:	Tom Horsley <horsley1953>
Component:	telnet	Assignee:	Harald Hoyer <harald>
Status:	CLOSED DUPLICATE	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	ast0002
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-11-09 18:27:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Horsley 2001-11-06 13:13:35 UTC

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.

Comment 1 Harald Hoyer 2001-11-06 13:19:06 UTC

can you please update util-linux and report if the problem still persists?

Comment 2 Tom Horsley 2001-11-06 23:58:38 UTC

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 17:08:29 UTC

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.

Comment 4 Andrew Turnquist 2001-11-08 21:36:51 UTC

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 10:15:27 UTC

Tom, do you also have tcsh? Then this problem maybe is a tcsh problem?

Comment 6 Tom Horsley 2001-11-09 18:27:53 UTC

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 13:41:31 UTC

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