Bug 62518 - in.telnetd is closed, child processes left running in background causing high CPU usage
Summary: in.telnetd is closed, child processes left running in background causing high...
Keywords:
Status: CLOSED DUPLICATE of bug 59029
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: telnet
Version: 7.2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-02 01:22 UTC by Rick Johnson
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-04-02 01:22:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Rick Johnson 2002-04-02 01:22:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)

Description of problem:
When a user abnormally closes a telnet session on a RH 7.1 or RH 7.2 box with 
rpm telnet-server-0.17-18.1 (RH 7.1) or telnet-server-0.17-20 (RH 7.2), certain 
remaining child processes left running will continue to run. Child processes 
will attempt to consume 100% cpu time, increasing the load average by a factor 
of 1 or 2 for each process left open.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Telnet to a RH 7.1 or RH 7.2 machine running the telnet server listed above, 
using any valid login.
2. Run the top command.
3. Abruptly disconnect your telnet session.
4. Log back into the machine, and view the process list.
5. Note the previous session's child processes and their CPU usage via top or 
ps -aux.
	

Actual Results:  Top process remained running at 100%. Performing 
the "experiment" a second time causes two processes to remain, each consuming 
about 50% CPU time, and increasing the load average by a factor of 1 or 2. 
Killing all non tty or pts associated login processes brings the system back to 
normal.

Expected Results:  When the telnet session was closed, all child processes 
should have immediately (or soon after) died.

Additional info:

We also experience this issue with the MicroFocus runtime (rts32) and our 
custom application. Top happens to be readily available, and displays the same 
problem. Other applications which may remain running, however may not consume 
resources would be watch, and also running make menuconfig within the linux 
kernel tree. Closing the session abruptly after any of these commands will 
leave the processes running.

While most users do log off properly, some will close their session without 
closing their applications, or they may become disconnected due to connectivity 
issues, which is where the bug surfaces.

Note: users using sshd do not experience this problem as it doesn't appear to 
call /bin/login for login processing.

Comment 1 Harald Hoyer 2002-04-02 09:17:03 UTC
As per #54741, this is fixed in util-linux-2.11n-8

*** This bug has been marked as a duplicate of 59029 ***


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