Red Hat Bugzilla – Bug 62518
in.telnetd is closed, child processes left running in background causing high CPU usage
Last modified: 2007-04-18 12:41:32 EDT
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):
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
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
Expected Results: When the telnet session was closed, all child processes
should have immediately (or soon after) died.
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.
As per #54741, this is fixed in util-linux-2.11n-8
*** This bug has been marked as a duplicate of 59029 ***