Version: (using Devel) Installed from: Compiled sources OS: Linux Konqueror opens many kio_http processes. Each takes about 2 MB of memory, which sums up to a lot when browsing for a while (this is much much more than Mozilla :)). For example, when I open http://last.fm, I immediately get about 11 kio_http processes. Closing Konqueror doesn't kill the processes, they need to be killed by hand. I'm using the most recent kdemod packages, with KDE 4.0.80-1.
It opens 17 kio_http to me ... using trunk r812722. Everyone use a lot of CPU and mem while the page loads.
and then they stay around. And which each site opened more kio_http instances accumulate. And konqueror. And kio_pop3 and kmail? never goes away. After some hours you either hit your fork limit or you oom. ...
*** Bug 169643 has been marked as a duplicate of this bug. ***
shouldn't this bug be assigned to KIO?
Problem persists in 4.1.1
Could you please make this a priority as Konqueror is next to unuseable because of all of the spawned processes being left behind. The result of this is that kde becomes very unresponsive. As a result of this I've been forced to make Firefox my default web browser. I miss Konqueror.
Also, nspluginwrapper and nspluginviewer processes seem to stack up as well as their konqueror processes. Just visit finance.google.com and visit the page for a single stock, then exit or open another in a different tab/window. You will have several nsplugin* processes gobbling up memory that stay _forever_. As an aside, konqueror processes never seem to exit *at all*, even with Settings -> Configure Konqueror -> Performance -> preloading max set to 0. This is not good.
Something changed in Fedora 9 between the release in the updates-testing and the move to the updates repository. You still get a lot of kio-http processes and they still take up quite a bit of memory, but when Konqueror is closed, it takes a while, but the running kio-http processes eventually close. If there is a change. I will let you know.
Wrote a little too soon. It would seem that things are better, but really not 100%. kio-http is still leaving being processes, but significantly less.
OK... the remainder of the kio-http processes may be coming from kmail. I need to investigate a little further.
This is back with a vengence in 4.1.2
This bug will kill konqueror. Please fix ASAP
Isn't this the same as #162612? This also affects me, including npviewer-processes and kioexec processes.
Bah, typo. I was referring to Bug #172566.
Problem persists in 4.1.3
Can we bump the severity level up on this? This bug is not just an annoyance--it's a show stopper. I've used konqy as my primary browser for 10 years, and I've stopped using konqy altogether because of this bug. It really is that bad.
16, you are right, this is a showstopper - and it is unfixed in svn. A lot of people have some ulimit setting to protect the system from fork bombs - and with the current kio_* misbehaviour you soon DOS yourself. It is really great if you can't even get a shell, because a bunch of kio processes blocks everything. Yeah, I know, switch to vt, log in as root, kill ' em - still that is just a workaround, not a solution and with the current state of video drivers, where a switch to vt and back can freeze your system, it is a very, very bad workaround.
My KDE 4.2 build doesn't seem affected. kio_http seems to be dying as expected. However, I have a 14 kio_file running, some of which have been running for almost a month. They are stuck in a select(2) call, waiting for activity in their incoming sockets. Unfortunately, I can't debug the older slaves. I can't see either which application they think they are connected to. I'll have to wait and see what happens. In any case, I have 12 slaves that are older than a day, in 26 days running. That doesn't count as DoS.
Found something interesting: there seems to be a file descriptor leak somewhere. My zsh processes inside konsole are connected to kdeinit4, which doesn't make sense at all. The sockets being duplicated in many processes and not closed properly would explain this bug.
You might be on to something. For me, both kdeinit4 and krunner processes tend to collect as well.
As for DoS, it might just be your usage pattern. If I click around finance.google.com a bit looking at stock charts, it doesn't take me long before I'll have 50-100+ nspluginwrapper, nspluginviewer, kio_http and konqueror --silent processes hanging around. These windows do auto refresh as well, so they are not even idle, even though they are "out of scope". If I do any google searching (krunner alt+f2, gg:<some search term>), then close the window when I'm done, there will always be two konqueror processes with that search term in their arg list that hang around indefinitely until I explicitely kill them. Do a search that takes you to a page with tons of plugins or looping js and it eats away cpu as well as ram. Thank god for htop...
I have built from svn today, and I still get this behaviour with konqueror. I closed all running instances, waited a bit and: 1000 24524 0.0 0.2 148820 9100 ? S 02:22 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmab11841.slave-so 1000 24528 0.0 0.2 148820 9128 ? S 02:22 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmal11841.slave-so 1000 24529 0.0 0.2 148820 9124 ? S 02:22 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmaZ11841.slave-so 1000 24530 0.0 0.2 148820 9084 ? S 02:22 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmaZ11841.slave-so 1000 24531 0.0 0.2 148820 9028 ? S 02:22 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-..../plasmat11841.slave-so 1000 24536 0.0 0.1 138984 5116 ? S 02:22 0:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmapkgX24533.slave 1000 24550 0.0 0.1 139084 5940 ? S 02:23 0:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../plasmay24546.slave- 1000 24559 0.0 0.1 138616 4128 ? S 02:24 0:00 kdeinit4: kio_about [kdeinit] about local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorF24558.sla 1000 24567 0.0 0.2 149380 9492 ? S 02:24 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorc24558.slave 1000 24570 0.0 0.2 149172 9264 ? S 02:24 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorB24558.slave 1000 24571 0.0 0.2 149044 9316 ? S 02:24 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorV24558.slave 1000 24572 0.0 0.2 148948 9184 ? S 02:24 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorn24558.slave 1000 24573 0.0 0.2 148948 9188 ? S 02:24 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorX24558.slave 1000 24595 0.0 0.1 42696 4488 ? S 02:24 0:02 /usr/lib64/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/lib32/nsbrowser/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins 1000 24840 0.0 0.1 140876 5904 ? S 02:33 0:00 kdeinit4: kio_file [kdeinit] file local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konqueroro24834.slave 1000 25414 0.0 0.1 138616 4128 ? S 02:51 0:00 kdeinit4: kio_about [kdeinit] about local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerors25411.sla 1000 25447 0.0 0.2 148820 9236 ? S 02:52 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerord25411.slave 1000 25451 0.0 0.2 148820 9224 ? S 02:52 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorr25411.slave 1000 25452 0.0 0.2 148820 9236 ? S 02:52 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorW25411.slave 1000 25453 0.0 0.2 148884 9200 ? S 02:52 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-...klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorZ25411.slave 1000 25472 0.0 0.1 42696 4424 ? S 02:52 0:00 /usr/lib64/nspluginwrapper/i386/linux/npviewer.bin --plugin /usr/lib32/nsbrowser/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins 1000 25607 0.0 0.2 148820 9176 ? S 02:54 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorF25411.slave 1000 25674 0.0 0.2 148820 9180 ? S 02:57 0:00 kdeinit4: kio_http [kdeinit] http local:/tmp/ksocket-.../klauncherT11689.slave-socket local:/tmp/ksocket-.../konquerorP25411.slave
*** Bug 178243 has been marked as a duplicate of this bug. ***
Having the same problem, OpenSUSE 11.1 KDE 4.2 binaries. I think that it might be kmail (and possibly akregator) causing the problem for me.
After further investigation, it seems to be caused by the kio_http process being denied access through my school's proxy. Instead of giving up, it just keeps trying, over and over and over again. Setting up the proxy through the System Settings doesn't change things, because I can't set my proxy username and password (it's grayed out) and it's not "prompting for password as necessary" like it says it will. It's also not obeying my system environment proxy settings. If I could set my proxy username and password, this problem may fix itself. However, unlike the others in this thread, instead of many kio_https I only get one.
Maybe another site to try is www.glob2.org kio_http processes instantly rise from around 10 to 102.
I get this in 4.2, no proxy and only Konqueror (with 5 tabs) open. I don't even know if they're safe to close
Bump. I get this in KDEmod4.2.2 on Arch64. OPening Konqueror with 4 tabs generates 50+!!! instances of kio_http.
I have this problem too when visiting a large webpages like http://iyalucu08.blogspot.com/ I didn't count how many kio_http processes I have, but they surely slow down my computer and eats my memory. This bug may be the same as #196117
going through the dilbert archives I hit the bug again after a while. Twice so far. Whenever sites with pictures are involved it happens. kde 4.3.60 from snv a few days ago gcc 4.4 glibc 2.10.1 qt-copy
Using KDE-4.4/kubuntu, I have the feeling that ioslaves still spawn in impressive numbers, but they shut down after a while. This may be just normal operation, but it's hard to tell, since there is no indication what each ioslave is doing at the moment.
Not only Konqueror. I think that is the full KDE engineers fault. Every request opens a new kio_http process. So any applications that use kio opens many new processes, whether Amarok (if you enable photos widget, for example), Ktorent etc. This applies not only to kio_http. Any protocols that supported by KIO works the same way. This isn't very noticeably with some application like Kmail ('cause I have 4 mail box and accordingly I can see 4 kio_imap4 after launching Kmail) but when I open my video folder (with 40-50 files) through Dolphin — it's a very different situation. Confirmation: http://bugs.kde.org/show_bug.cgi?id=185881 http://bugs.kde.org/show_bug.cgi?id=202308 http://bugs.kde.org/show_bug.cgi?id=203628 http://bugs.kde.org/show_bug.cgi?id=234030 Now, for convenient KDE using, I needed 32Gb of RAM and Intel Core i7-980X Extreme Edition processor. Experience Freedom!
The issue with ioslave explosions should have improved after the 4.4.1 release. See http://websvn.kde.org/?view=revision&revision=1071917 and should have gotten a whole lot better after the new KIO scheduler was released with KDE 4.5. If any of you still have experience this issue with the KDE v4.5 and up, please speak up and comment on this ticket. Otherwise, this report should be marked fixed.
See comment #33.