Bug 14998

Summary: top and other programs run amok with FreeBSD3.3 (Release and Stable)
Product: Base System Reporter: hans.wander <hans.wander>
Component: miscAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description hans.wander 1999-11-19 21:30:00 UTC
we have a major problem with our FreeBSD 3.3 boxes (they are
planned to be proxy servers)
 
Try the following commands and tell me your experiences (and
possibly a fix/workaround):
 
- telnet from a remote machine to your FreeBSD box
- login as ordinary user (not as root!)
- su (all following tasks are run under root account)
- run top
 
The process chain is now: telnetd - shell - su - top
the process owners are:    root     user    root root
 
Now kill the corresponding telnetd task from another root shell
and voila: telnetd has disappeared, but after some seconds
top sucks the CPU time 99% (on a single CPU machine)
 
Please don't ask "which fool would kill telnetd?"
exactly this happens, if you telnet from another FreeBSD box
in an xterm, then start "su" and "top" and finally kill the xterm 
without having killed the "top" task.
(there is this neat M$ish "X" button on the top right of the window :-(
top reports lots of IO errors in an endless loop (can be viewed with
truss)

I feel there's a major problem with FreeBSDs signal handling or
something

How-To-Repeat: telnet from a remote machine to your FreeBSD box
login as ordinary user (not as root!)
su (all following tasks are run under root account)
run top (or "more /etc/passwd")
Now kill the corresponding telnetd task from another root shell
and voila: telnetd has disappeared, but after some seconds
top (or more) sucks the CPU time 99% (on a single CPU machine)
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 1999-11-20 06:26:42 UTC
State Changed
From-To: open->closed

Duplicate of PR 14932.  This issue is under investigation under that PR. 

You should probably know that high CPU utilization reported does not 
necessarily mean that if other processes needed CPPU time, they 
wouldn't get it.  If the machine is mostly idle, a spinning process 
will use the available CPU time, which is obviously "most" of it. :)