Bug 211956 - top goes into hard loop on xterm exit
top goes into hard loop on xterm exit
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: procps (Show other bugs)
4.4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
:
: 211957 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-24 00:16 EDT by Major
Modified: 2007-11-16 20:14 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-24 06:26:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Major 2006-10-24 00:16:51 EDT
Description of problem:
top run as root goes into hard loop if the xterm it is running under exits

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

How reproducible:
100%

Steps to Reproduce:
1. Start an xterm
2. su to root
3. run top
4. kill the xterm
  
Actual results:
top process goes into hard loop consuming 100% of available cpu

Expected results:
top process terminates

Additional info:
Comment 1 Karel Zak 2006-10-24 06:17:17 EDT
*** Bug 211957 has been marked as a duplicate of this bug. ***
Comment 2 Karel Zak 2006-10-24 06:26:22 EDT
Your xterm runs with non-root permissions and it can't send SIGHUP to the su
which runs with root permissions. This problem cannot be fixed. Sorry.

BTW, I you want to run the top with root permissions in a xterm, you can start
it by: su -c "xterm -e top".
Comment 3 Albert Cahalan 2006-12-25 14:08:15 EST
This is actually a kernel bug.

The xterm itself DOES NOT send the SIGHUP. The SIGHUP is sent by the kernel
itself, automatically as the xterm dies.

On a real BSD system, where this whole idea originates AFAIK, the signal will
always get sent. Linux used to do this too, but broke when some other changes
went it. I believe it was the SE Linux merge that caused this, but note that the
bug shows up even when SE Linux is not compiled into the kernel. In other words,
I think the SE Linux changes broke non-SE systems.

I've been unable to find the bug from an examination of the kernel source. As
far as I can tell, the signal is sent in a way that will bypass permission
checking. Somehow though, this isn't working.

Please reopen this bug and assign it to the kernel.

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