When top is running in a terminal emulator (Konsole, xterm) from within "su", and the terminal is closed, it keeps running and hogs the CPU. Reproducible: Always Steps to Reproduce: 1. Open a terminal emulator (as a user) in a desktop session. I've tested Konsole and xterm from within KDE 4.5.1. 2. su 3. top 4. while top is running, close the terminal window Actual Results: top keeps running, and eats all CPU. pstree shows: init─┬ ... ├─su───bash───top Expected Results: top should exit when terminal is closed.
I can't reproduce that with x11-terms/rxvt-unicode under x11-wm/musca. I also doubt it's a problem with sys-process/procps. Please post your `emerge --info'. A gdb backtrace of the top process in question would also be nice.
Created attachment 246374 [details] backtraces I also cannot reproduce it x11-terms/rxvt-unicode. I am sure you will be able to with Konsole and xterm, because others have too. I am attaching three backtraces
Created attachment 246376 [details] paludis --info sys-process/procps
I am able to reproduce that with x11-terms/terminal and xterm. Not sure, however, how could we fix this... I guess the terminal simply is unable to send SIGHUP to 'su' as it is setuid. This is a very general issue, and it seems not really related to a particular terminal. On the other hand, I can't reproduce it on a login shell...
(In reply to comment #4) > I guess the terminal simply is unable to send SIGHUP to 'su' as it is setuid. This is not true; the bug can be reproduced even if xterm is running as root (I believe the terminal does not need to send SIGHUP to the program; it is sent by the kernel when the controlling end of the pseudo-terminal is closed). IMO, this is an issue with top and not any terminal, since top is the process caught in an infinite loop. Even if it's waiting for something, busy waiting is the wrong thing to do.
I've retried this with gdb-attached top and it doesn't receive SIGHUP at all. Neither does su or bash running it.
Created attachment 248336 [details, diff] Patch to fix the issue Ah, got it. Someone smart wanted to optimize the code too much.
I've reported the issue upstream. Hope sourceforge does deliver messages better than it archives them.
Seems fixed using sys-process/procps-3.3.2_p2-r1