' this is done with the 'f' option of ps, so for example ps aufx will demonstrate that. But it is the honesty of our mistakes that make us look good3) 'Try viewing the processes in a tree and see if there isn't a zombie somewhere, or maybe something sleeping. Open Source is great because the community deals with problems when they arise, so it may seem like Linux/KDE/Suse developers are perfect. Linux/KDE/Suse developers do make bugs, assuming otherwise prevents the bug from being fixed. Think about the classic 'while( variableThatIsTrue ) ' mistake in C.2) 'This is most likely not a suse bug.'. Second 100% cpu is not necessarily a 'stdin is tied to stdout' there are lots of ways to create 100% cpu.

Sending a kill to the client. Usually the real fix has nothing to do with dbus-daemon but the client program that is sending continuous requests to the daemon. Many people have had 100% CPU dbus-daemon problems. Web-server) it interacts with other programs in a client server relationship. The dbus-daemon is a daemon and just like other daemon's (eg.

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. Try it, but I would not be surprised if nothing is shown. 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(. For many people this has been sufficient at identifying the offensive program. Check top and see if there some other program with small CPU kinda hanging near the top. I personally am unaware of a good way at tracking the offending client though so cannot help you there.

Next time just answer in french.As noted, it appears it was that posters intention to spur exactly theResponse you gave.his posts were NOT helpful and he was not and isNot a member of the 'linux community' instead a FUD merchant.

Linux Dbus Daemon