Version: 1.6.5 (using KDE KDE 3.5.5) Installed from: Gentoo Packages Compiler: sys-devel/gcc-4.1.1-r3 OS: Linux If I run top as root in a konsole window, then click the window away without 'q'-ing or ctrl-c'ing out of top, then the top process goes zombie and claims 100% of cpu. I have reproduced this on 2 different machines. Here is the output of a second 'top' (not run as root): jesnow@Merckx ~ $ top -b top - 11:27:32 up 55 min, 1 user, load average: 0.71, 0.28, 0.21 Tasks: 97 total, 3 running, 94 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 0.9%sy, 0.5%ni, 94.1%id, 1.8%wa, 0.0%hi, 1.2%si, 0.0%st Mem: 1034048k total, 374728k used, 659320k free, 38504k buffers Swap: 506008k total, 0k used, 506008k free, 178408k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11867 root 25 0 2176 1108 828 R 99 0.1 0:28.91 top 6452 root 15 0 79356 39m 5800 S 2 3.9 0:22.40 X 1 root 15 0 1532 536 464 S 0 0.1 0:00.79 init 2 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0 3 root 34 19 0 0 0 R 0 0.0 0:00.00 ksoftirqd/0 4 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1 5 root 34 19 0 0 0 S 0 0.0 0:00.00 ksoftirqd/1 6 root 10 -5 0 0 0 S 0 0.0 0:00.02 events/0 7 root 10 -5 0 0 0 S 0 0.0 0:00.00 events/1 8 root 10 -5 0 0 0 S 0 0.0 0:00.01 khelper
I can reproduce this using KDE 3.5.6, Kubuntu packages. This is not reproducible in my KDE 4 branch.
To me it seems like 1) konsole is failing to kill the root process I started and 2) the 'top' process does something once it becomes parentless that uses all that cpu. 1) Could be because my konsole instance doesn't have the rights to kill a running root process. But then the bash shell would be left similarly ownerless, and that doesn't happen. 2) Requires some special activity in top to grab all that cpu. Loop.c (below) exhibits the same behavior when run as root. You start it as root, click the window away, then it remains there un-dead, looping away. Depending on how top calculates its wait period, maybe it grabs all that cpu because the display output has become so fast (because there's no display?), and so it executes its main loop more often. main () { int i; while (1) { i++; // this is so the loop for sure doesn't get optimized away. } return i; } Seems like this could be a security issue if a root process can outlive its parent. I've been annoyed by this behavior for years, I'm amazed nobody has complained about it until now.
All, termination of a shell session is a somewhat complicate topic in Linux and Unix. http://www.gnu.org/software/libc/manual/html_node/Job-Control.html#Job-Control summarizes its basics. What the konsole (and any other terminal, be it the linux console and the xterm (clones)) do is more or less the same. To summarize, closing the pty causes a SIGHUP being sent to the session leader (e.g. shell) via the OS. This either does proper cleanups, or, if the session leader is a stupid program, the OS tries to be helpful in cleaning up the orphaned process groups by sending a SIGHUP. (It is more complicate, really.) Thus, the described effect should either be reproducible under any terminal or clearly indicates an error in the setup of the pty and or the session in the konsole. And indeed, i was able to reproduce the behaviour with xterm. My suspicion is that 'su' is to be blamed, really, but that's only wildly guessing. I called your program 'termtest': $ xterm $ su # ./termtest (simply closing (X) the xterm) 'top' still shows termtest running. Hope it helps Lars On Thursday 05 April 2007 22:12, Jonathan E.Snow wrote: [bugs.kde.org quoted mail]
Ok, > My suspicion is that 'su' is to be blamed, really, but that's only wildly guessing. Which was a wrong guess... I did one more test, and the problem can indeed be located to the konsole's pty/session code. I made a test with a variant of the konsole that uses forkpty(3), which does the pty and session stuff right. ./termtest was cleaned up then as it should under su. Not using forkpty and mess of replacements and hacks around ptys instead, was historically due for the unavailability of glibc2 under many systems at that time. -lars
I suspected it must be in Konsole, and that also explains why it doesn't do that in kde 4, which probably uses clean glibc2 code. Beste Gruesse aus Texas! Jon Snow. Lars Doelle wrote: [bugs.kde.org quoted mail] - -- - ---------------------------------------------------- Dr. Jonathan E. Snow Department of Geosciences S&R 1, University of Houston Houston, TX, 77204 fax:713-748-7906 email: jesnow@uh.edu tel:713-743-5312 - ---------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIPLzBgXrDLuafh8RAhHHAJ93t+c8ZVnJ4rMFCQ1niuYUfZMIFACfTqn2 OHjp1aSVF2jVcnLax0AVL2g= =4VzH -----END PGP SIGNATURE-----
*** Bug 148236 has been marked as a duplicate of this bug. ***
Still valid in KDE 4. Sample output from "sudo strace -p <PID OF TOP>" write(1, "\33[H\33[m\33(Btop - 14:38:40 up 5 day"..., 2048) = -1 EIO (Input/output error) write(1, "\33[H\33[m\33(Btop - 14:38:40 up 5 day"..., 2048) = -1 EIO (Input/output error) write(1, "\33[H\33[m\33(Btop - 14:38:40 up 5 day"..., 2048) = -1 EIO (Input/output error)
I don't know if my symptom is related yet or not, but just FYI, I'm occasionally seeing 100% utilization by konsole. The duration is from momentary (somewhat anticipatable) to well over ten minutes (well over unacceptable). KDE Release 3.5.7 "release 72.6" on SuSE 10.3 for x86-64.
> I don't know if my symptom is related yet or not, Is the problem reproducible?
*** Bug 164789 has been marked as a duplicate of this bug. ***
I notice the same behaviour in xterm and gnome-terminal. The 'top' process is still running, it is not a zombie.
Is this report still valid? I can't reproduce it with any of konsole-2.7.999, xterm-270 and gnome-terminal-3.0.1 .
This looks like a KDE 3 issue.
On KDE 4.6.5 running less monitoring a file in a su shell leaves less running after konsole is killed. This looks still valid to me.
(In reply to comment #14) > On KDE 4.6.5 running less monitoring a file in a su shell leaves less running after konsole is killed. This looks still valid to me. That seems a different problem. The original report is when konsole is closed *in a normal way*, not killed, it leaves the su top running. And I can't reproduce your problem with zsh/bash and konsole-2.7.999
I'm sorry, I meant "after konsole is closed". less, which monitors the file with Shift-End, stays running and consumes 100% CPU after some time.