Bug 62518

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.