I don’t know if anyone else has experienced the problem I am about to describe. I don’t know if it is a bug, or even a recognized problem, or if this is the right place to post, but…
Over a couple of reinstalls of 12.1 x86_64, KDE 4.8.4, on a couple of different machines, I have had problems with kdesu. The problem is this: if I do “kdesu something” a few times, the system will get to the point where it takes about 30 seconds for the application to open. Sometimes it doesn’t open at all. The same thing happens when invoking “File Manager - Super User Mode” from the Applications menu. After looking into this a bit I found that System Monitor was loaded with “dbus-launch” and “dbus-daemon” processes, all owned by root. I also saw that each time I would try to open “File Manager - Super User Mode” again, or run another “kdesu something”, another “dbus-launcher” and “dbus-daemon” would appear, and would then persist after the application was closed. I then found that if I went through and killed all these dbus processes that were owned by root, the system would become responsive again, only to slow down again as the dbus stuff would reaccumulate.
I managed to fix this behavior by doing the following:
I changed to “command” in the “File Manager - Super User Mode” launcher from “dbus-launch dolphin %i -caption “%c” “%u”” to “dbus-launch --exit-with-session dolphin %i -caption “%c” “%u””.
I added the following line to my .bashrc file: alias kdesu=‘kdesu dbus-launch --exit-with-session’
Now the dbus-launcher and dbus-daemon both go away after the respective application is closed, and things don’t slow down after repeated openings.
Any comments, explanations, critiques, or scoldings about this would be welcome.
Your discoveries seem very interesting. What I have found of late is I just remove the dbus-launch command entirely, even when running these apps from a script. Just don’t run them as root and use the kdesu (or gnomesu) command if you need to be root to start them or use the run as different user, when part of the menu system. Here is a link about the dbus-launch command:
So have you tried to start of say Dolphin without the dbus-launch command and its options? I find it works properly without this command. I am thinking there may be a problem with dbus-launch or that we just don’t understand when it should be used, if at all.
Try this: open up your System Monitor. Then open a terminal and run “kdesu kwrite”. If your system behaves the same as mine, you will see two new processes appear, a “dbus-launch” and a “dbus-daemon”, both owned by root. Then close kwrite and the terminal. Again, if your does the same as mine, those two processes will persist. Do “kdesu kwrite” again, and two more processes will appear, etc.
I have been weakly tempted to do a complete reinstall on my laptop and see if a fresh unadulterated installation behaves the same way. I have wondered if there is some environment variable to set that will take care of this issue.
So in openSUSE 12.1 using dbus-launch from terminal causes the behavior as you suggest leaving a copy of dbus-deamon assigned to messagebus, but I can load kwrite from a terminal session using only kdesu kwrite as a standard user with no dbus entries made and it works properly. Further, there may be an additional problem in openSUSE 12.2 as using dbus-launch actually makes the whole session unstable requiring a restart to get back to normal. In my estimation, what you see is true, but again I question the need to use dbus at all. On a clean restart of openSUSE 12.1 64 bit I found two dbus-launch’s in system monitor, one by root and one by me as a user and three dbus-daemon’s loaded. No matter what I do normally, I do not see these change except if using dbus-launch without the option you specify which leaves a copy of dbus-daemon assigned to the messagebus. Again, I would suggest to stop using dbus-launch if you can. There could be something wrong perhaps with your install, but it can be avoided I think. In any event, I would hold off I think with a new install of openSUSE 12.1 until we get openSUSE 12.2 out in September and then go for it instead.
It seems that the problem is initiated by running “File Manager - Super User Mode” from the System->File Manager menu. If you do this at least 3 times, then it along with kdesu commands take at least 30 seconds to appear. If you never run “File Manager - Super User Mode”, then kdesu will continue to function normally. I think this is somehow related to the fact that “File Manager - Super User Mode” is invoked by the kicker menu with the command “dbus-launch dolphin %i -caption “%c” “%u””. I edited this to the following: “kdesu dolphin %i -caption “%c” “%u””. I also got rid of the “alias” entry that I had put into the .bashrc file. Everything functions normally now. I even confirmed all this by reinstalling 12.1 KDE with no updates on my notebook and it acts the same way. So it seems now that invoking the file manager in Super User mode with the “dbus-launch” command (as it is done in the kicker menu) is the culprit.
I suppose the folks at KDE would be interested in this, but I would like for someone else to reproduce it before I report it.
Since you went into the issue deep enough, I do suggest you make a bug report to KDE about the issue. I can also confirm what you have been seeing and that somewhere around openSUSE 12.1 and KDE 4.7, this issue has come to life and exists even worse in openSUSE 12.2 and KDE 4.8. I had not really looked at the default menu options for Dolphin before and the discovery of this unneeded entry is good to know in that it can be edited and removed from creating trouble. I can also say its still not clear to me why I need to use dbus-launch in the first place, but there must be a good reason there somewhere.
I submitted a bug report to KDE. They replied that it was in fact an openSUSE implementation of the command to open the File Manager in Super User Mode and suggested that I report the bug to Novell, which I did.
Hey that is good follow through on the issue evetsnameloc and thanks for the update. Its interesting openSUSE feels the need to add dbus-launch, but we still do not know for sure why it is done.