.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21072 **** 20 0 47328 13m 660 R 100 0.7 519:29.81 dbus-daemon
.
The only way I have found to fix this is to restart KDE when it happens. I’d really like my linux box to be more reliable/stable than windows, is there any way to fix this?
Terminal apps? I’m just running normal kde programs, kwrite, firefox, etc…
Apparently, since you can see the PID you have tried to kill it with no success.
I did kill 9 it a few weeks ago when it cropped up. IIRC the daemon did go away, but I still couldn’t launch anything new (via command line or kde icon)
Try viewing the processes in a tree and see if there isn’t a zombie somewhere, or maybe something sleeping.
Not sure how this is done, can you give a little more guidance? Thanks
If you’re writing your own terminal apps, you may need to write some assembler routines to catch this problem, or run a “watcher” thread to send a sigkill to the app when it starts running wild.
I’m not a programer… so that’s not it. Again, this box is just running normal KDE desktop stuff.
This is most likely not a suse bug.
hmmm
Clever of them to not even change broken code they rip off, eh?
In the interest of getting the correct solution to this problem I am going to challenge some assumptions here…
100% cpu does not mean that stdin is tied to stdout and that kill 9 will not work… this is just plain false… depending on how the application is built the program should still respond to kill commands… Second 100% cpu is not necessarily a “stdin is tied to stdout” there are lots of ways to create 100% cpu. Think about the classic “while( variableThatIsTrue );” mistake in C…
“This is most likely not a suse bug.”… Linux/KDE/Suse developers do make bugs, assuming otherwise prevents the bug from being fixed… Open Source is great because the community deals with problems when they arise, so it may seem like Linux/KDE/Suse developers are perfect… but it is the honesty of our mistakes that make us look good
"Try viewing the processes in a tree and see if there isn’t a zombie somewhere, or maybe something sleeping. " this is done with the “f” option of ps, so for example ps aufx will demonstrate that… however this is not perfect as not all forks are shown in ps aufx…
Ok so now for some constructive advice. The dbus-daemon is a daemon and just like other daemon’s (eg. web-server) it interacts with other programs in a client server relationship. Many people have had 100% CPU dbus-daemon problems. Usually the real fix has nothing to do with dbus-daemon but the client program that is sending continuous requests to the daemon. Sending a kill to the client… or updating the offending client will generall solve the problem. I personally am unaware of a good way at tracking the offending client though so cannot help you there. Check top and see if there some other program with small CPU kinda hanging near the top… for many people this has been sufficient at identifying the offensive program. Now the issue with client-server structure is ps f will not show there is a connection because the f option only shows the forks and the “processStart( … )” results. Try it, but I would not be surprised if nothing is shown… Another problem with kill directly to the daemon is that most kde application expect that daemon to exist and will not start if they cannot find it so that is why nothing opens when dbus-daemon is either killed or crapping out…
Ok… what happened to the first reply? Deleted because someone disagreed with it?
100% cpu does not mean that stdin is tied to stdout and that kill 9 will not work… this is just plain false… depending on how the application is built the program should still respond to kill commands… Second 100% cpu is not necessarily a “stdin is tied to stdout” there are lots of ways to create 100% cpu. Think about the classic “while( variableThatIsTrue );” mistake in C…
Thank you for demonstrating so clearly a problem with the linux community (that claims it is so willing to help.)
Someone with a problem states they’re not a programer and you go into stdin and C variables. umm thanks. Next time just answer in french.
“This is most likely not a suse bug.”… Linux/KDE/Suse developers do make bugs, assuming otherwise prevents the bug from being fixed…
Yet your first assumption is that it’s not a KDE/Suse issue. Especially interesting as you then state lots of folks run into similar dbus issues.
Open Source is great because the community deals with problems when they arise, so it may seem like Linux/KDE/Suse developers are perfect… but it is the honesty of our mistakes that make us look good
Even a novice like myself could point out the falsehood here by directing you to bug tracker tickets that go into an almost infinite loop of closed/re-opened because of developers denying an issue exists, then other users/developers proving it does… but that’s not (well, wasn’t) the point of this thread.
Many people have had 100% CPU dbus-daemon problems. Usually the real fix has nothing to do with dbus-daemon but the client program
Wait… I though open source issues were solved quickly because of the honesty of our mistakes. I already stated I’m just using the basic apps that come with Suse 11.4 and KDE. All open source to the best of my knowledge. Just a basic desktop setup doing little more than web surfing and email.
. Sending a kill to the client… or updating the offending client will generall solve the problem.
According to YAST, everything is up to date.
Check top and see if there some other program with small CPU kinda hanging near the top…
On 10/08/2011 05:06 PM, WyattOil wrote:
>
> Ok… what happened to the first reply? Deleted because someone
> disagreed with it?
after a week of disruptive and baseless rants the poster began a
campaign of consistently bad (or partially bad and wholly dangerous)
advice…causing several folks needing to go into threads all over the
place and try to undo the potential damage, spewed…
after several threads were repaired, the disruptor requested a mod to
delete his account… and, it was…
> Thank you for demonstrating so clearly a problem with the linux
> community (that claims it is so willing to help.)
> Someone with a problem states they’re not a programer and you go into
> stdin and C variables. umm thanks. Next time just answer in french.
as noted, it appears it was that posters intention to spur exactly the
response you gave…his posts were NOT helpful and he was not and is
not a member of the “linux community” instead a FUD merchant…
>> Check top and see if there some other program with small CPU kinda
>> hanging near the top…
> The top of what, top ?
so, open a terminal, type in
top
and press enter…the
display will display lots of memory data at the very top and then a
changing line up of applications listed in order of the resources they
are consuming…if you see one staying at the “top of top” it usually
is an indication that something is flaky with that app (a normally
behaving system will have different apps jump to the top of top (if you
are doing things other than just watching top–so open it where you can
see it, and then do other stuff like email, browsing, whatever and top
will constantly report what is sipping (or sucking up all of) the ticks…))
–
DD Caveat
openSUSE®, the “German Automobiles” of operating systems
On 10/09/2011 03:53 PM, Carlos E. R. wrote:
> And entire threads. :-?
i don’t know…
i have not checked…
but there was one (at least) originated by the disruptor which served no
useful purpose that i could see…unless FUD is a useful purpose.
here, i see that one post in this thread is no longer on the web side
(but is still on the nntp side…compare post #2 on both mediums…)
–
DD
openSUSE®, the “German Automobiles” of operating systems
that explains why that idot gave such **** advice!!!
WyattOil Je parle en francais un petit pue. WyattOil I think you should recognize I was trying to straighten this post out so that you get real and honest advice isn’t that helpful? The truth is I wasn’t speaking at a newbs level for your sake, I was speaking to rainbowsally hence all the use of similar jargon.
I never made that assumption… In fact quite the opposite…
Advice giving (like what I am doing here) and fixing bugs are all volunteer activites where no one is paid… so minor issues do fall through the cracks… much like advice givers do not always take the time to spell it out in verbose detail…
Like I said the dbus at a 100% does not affect things in a major way on multi-core CPU’s. However like I was alluding to in the original post this is a very difficult symptom to diagnose. The problem is in an offending client and realistically you have to wait for the team behind that client realizes it. The reality about open source (along with all other software programs) is that they are almost never perfect. So in general major errors that are easy to fix are solved quickly, hard to solve but minor errors… frankly the work vs. reward isn’t there for a fast fix…
Good
as stated in other posts top is a command line program. Open a terminal and give it a try…
Ok just a reply post… Lets get this thread back to the original problem… I am actually interested in the clean solution…
I had this problem until two days ago - every 3 or 4 days dbus-daemon would go crazy and sit on 100% CPU. Do you have any other issues when this is occurring?
For me I couldn’t open new instances of Firefox, Dolphin, Gedit, etc.
So (via KDE bug report: Bug 261180 - dbus-daemon runaway at 100% CPU ) I tracked it down to kpackagekit opening a stupidly large number of processes that over the course of 3/4 days would mean I’d reached my process limit.
I stopped the kpackagekit icon auto-starting using System-Settings -> Startup -> Service Manager and all is now fine.
Means I have to run “zypper lu” myself now, but better than a mangled desktop…
Of course, this may be irrelevant but worth a try, especially as the bug you get seems to exhibit similar behaviour - i.e. occurs after an extended period of uptime.
//
Here’s my system info:
cat /proc/version
Linux version 2.6.37.6-0.7-desktop (geeko@buildhost) (gcc version 4.5.1 20101208 [gcc-4_5-branch revision 167585] (SUSE Linux) ) #1 SMP PREEMPT 2011-07-21 02:17:24 +0200
> I stopped the kpackagekit icon auto-starting using System-Settings ->
> Startup -> Service Manager and all is now fine.
yes! many folks in many posts in several forums have, since 11.4 came
out, advocated/advised all to turn off/disable or even uninstall
kpackage kit…and use zypper or yast online update instead.
–
DD
openSUSE®, the “German Automobiles” of operating systems
