This is related to "kde-base/kdebase-startkde" I stumbled upon this because after the upgrade to kde 4.11.2 Kontakt stopped to work at some point as Akonadi did not want to start because some Agents could not be started because they seemed to be already running. From the akonadi error log: "Unable to register service as org.freedesktop.Akonadi.Control.lock Maybe it's already running?" After some search I found the problem in /usr/bin/startkde where XDG_DATA_DIRS was set to include two times /usr/share instad of /usr and /usr/share. Please see the fix below. --- startkde_org 2013-10-10 13:15:41.000000000 +0200 +++ startkde 2013-10-17 10:08:45.330789511 +0200 @@ -267,9 +267,9 @@ echo 'startkde: Starting up...' 1>&2 # to set it to a list of paths *not* including the KDE prefix if it's not /usr or # /usr/local. if test -z "$XDG_DATA_DIRS"; then - XDG_DATA_DIRS="/usr/share:/usr/share:/usr/local/share" + XDG_DATA_DIRS="/usr:/usr/share:/usr/local/share" else - XDG_DATA_DIRS="/usr/share:$XDG_DATA_DIRS" + XDG_DATA_DIRS="/usr:/usr/share:$XDG_DATA_DIRS" fi export XDG_DATA_DIRS Maybe it is better to invoke "kde4-config --prefix" instead of hardcoding it: XDG_DATA_DIRS="`kde4-config --prefix`:/usr/share:/usr/local/share" But as the comments in the script state, KDE prefix has to be the first in the line. I did not test if this error is because of a duplicate entry of /usr/share or if it is because of the missing /usr dir. But the above fixed it for me. Kind regards, Bjoern
Interesting, I rebooted today and akonadi failed to start, I rebooted again and akonadi started perfectly fine. So somewhat inconsistent... I'll keep tracking it.
(In reply to Bjoern Olausson from comment #0) > > Please see the fix below. > > --- startkde_org 2013-10-10 13:15:41.000000000 +0200 > +++ startkde 2013-10-17 10:08:45.330789511 +0200 > @@ -267,9 +267,9 @@ echo 'startkde: Starting up...' 1>&2 > # to set it to a list of paths *not* including the KDE prefix if it's not > /usr or > # /usr/local. > if test -z "$XDG_DATA_DIRS"; then > - XDG_DATA_DIRS="/usr/share:/usr/share:/usr/local/share" > + XDG_DATA_DIRS="/usr:/usr/share:/usr/local/share" > else > - XDG_DATA_DIRS="/usr/share:$XDG_DATA_DIRS" > + XDG_DATA_DIRS="/usr:/usr/share:$XDG_DATA_DIRS" > fi > export XDG_DATA_DIRS (In reply to Bjoern Olausson from comment #1) > > Interesting, I rebooted today and akonadi failed to start, > I rebooted again and akonadi started perfectly fine. I encountered the same type of problem, but on 4.10.5. I did - XDG_DATA_DIRS="/usr/share:/usr/local/share:/usr/share" + XDG_DATA_DIRS="/usr:/usr/share:/usr/local/share" because I assumed that $XDG_DATA_DIRS before this conditional would in the else case be "/usr/share:/usr/local/share". I rebooted, and akonadi started, but an `echo $XDG_DATA_DIRS` still gives /usr/share:/usr/local/share:/usr/share (as before)! I'll apply else - XDG_DATA_DIRS="/usr/share:$XDG_DATA_DIRS" + XDG_DATA_DIRS="/usr:$XDG_DATA_DIRS" and check again next boot (curious to see whether akonadi will be flakey for me as well) and report back at that time.
*** Bug 487590 has been marked as a duplicate of this bug. ***
(In reply to Erik Quaeghebeur from comment #2) > > I'll apply > > else > - XDG_DATA_DIRS="/usr/share:$XDG_DATA_DIRS" > + XDG_DATA_DIRS="/usr:$XDG_DATA_DIRS" Ok, now I get /usr:/usr/local/share:/usr/share for XDG_DATA_DIRS, so at least for me the else clause is evaluated and XDG_DATA_DIRS starts out as /usr/local/share:/usr/share before that. (You quite likely know all this; if so, sorry for the noise.) Akonadi has started upon boot ever since I first reported; I do have some doubt it was due to this change, however.
I can confirm this behavior of akonadi on my gentoo with KDE 4.11.2. I have to kill akonadi at each login and start it manually to come up. When it starts automatically it is running and seems like dead (it does nothing and logs no errors but mysql, akonadiserver and akonadi_control are all started). When you start Kontact it tries to fire up akonadi and times out with an error. You have to kill akonadiserver, akonadi_control and mysqld and then start akonadi again. Changing XDG_DATA_DIRS made no difference. I use systemd and user session is started properly. I can query systemd and dbus.
My Duplicate bug was fixed by applying the patch referred to in this bug. The only difference between Tim Eberhardt and myself is that I'm still using openrc. My Wireless Driver(b43) is unstable with systemd to say the least...
Carter Young, did you have the agent errors as stated by Bjoern Olausson? I had those errors several times. Now akonadi (after I set up akonadi and even my home a few times from scratch) just refuses to start correctly without error. So I'm not sure if this is the correct bug for my problem but I know those akonadi agent errors Bjoern Olausson reported. As next step I'll try to disable nepomuk.
See my closed bug, bug 487548, which contains the error i was getting. I'm not great with patch, so I edited /usr/bin/startkde by hand using kdesudo kate. Disabling nepomuk does no good. Use the akonadi tray app which will run the test suite on failure. After running the testsuite i ran akonadictl restart from a terminal to generate the output in the bug I submitted. If your output is identical, applying this fix will help. If not, post the output here, and I'll see if I can help. (In reply to Tim Eberhardt from comment #7) > Carter Young, did you have the agent errors as stated by Bjoern Olausson? I > had those errors several times. Now akonadi (after I set up akonadi and even > my home a few times from scratch) just refuses to start correctly without > error. So I'm not sure if this is the correct bug for my problem but I know > those akonadi agent errors Bjoern Olausson reported. As next step I'll try > to disable nepomuk.
My Apologies, that bug should be bug 487590 (In reply to Carter Young from comment #8) > See my closed bug, bug 487548, which contains the error i was getting. I'm > not great with patch, so I edited /usr/bin/startkde by hand using kdesudo > kate. Disabling nepomuk does no good. Use the akonadi tray app which will > run the test suite on failure. After running the testsuite i ran akonadictl > restart from a terminal to generate the output in the bug I submitted. If > your output is identical, applying this fix will help. If not, post the > output here, and I'll see if I can help. > > (In reply to Tim Eberhardt from comment #7) > > Carter Young, did you have the agent errors as stated by Bjoern Olausson? I > > had those errors several times. Now akonadi (after I set up akonadi and even > > my home a few times from scratch) just refuses to start correctly without > > error. So I'm not sure if this is the correct bug for my problem but I know > > those akonadi agent errors Bjoern Olausson reported. As next step I'll try > > to disable nepomuk.
Carter Young, thanks for your help but I don't know if my problem is related to this bug as the changes in startkde made no difference and for some days now akonadi isn't logging any errors anymore. It's just not starting up correctly. I don't want to hijack this bug. I will test a bit more and may open a new bug.
I have been running my system now for some time with my proposed changes but I must admit that it is still more like a gamble if my mail show up or not. So looks like those changes are only on part of a bigger problem. Because an "echo $XDG_DATA_DIRS" in the "konsole" gives me: /usr/local/share:/usr/share Although my settings in startkde - you obviously know -: if test -z "$XDG_DATA_DIRS"; then XDG_DATA_DIRS="/usr:/usr/share:/usr/local/share" else XDG_DATA_DIRS="/usr:/usr/share:$XDG_DATA_DIRS" fi export XDG_DATA_DIRS So where else is XDG_DATA_DIRS set? Cheers, BJoern
Okay, I know this sounds really really really odd, but: From bug https://bugs.gentoo.org/show_bug.cgi?id=487548 I ended up here, and after various attempts of finding the root cause for this, I was looking through bugs.gentoo.org, gentoo forums and other places. Apparently lots of people have issues with the nvidia 331.* drivers which cause compilation fails and all kind of weird behaviour, including lots of dbus issues. Hence I downgraded my nvidia driver to 325, rebooted about 7 times by now and never had this issue again, while I had the issue on every second reboot so far. In the other report the person, as per emerge --info, is running nvidia as well. I am aware that this sounds odd and completely unrelated, but: are you running nvidia drivers, and if: the 331 series? And if: is the problem still there when you downgrade? I am no longer able to reproduce this.
I downgraded nvidia-drivers from 331.17 to 325.15 as well and the following reboot worked flawless. Lets see what the following reboots in the next days will bring - lets hope for the best. But if this should really be related to the nvidia-driver, then this is more then weird... Cheers, Bjoern
I'm experiencing similar issues (and also have been using 331 nvidia kernel dirvers). I had been getting around the issue by killing off the akonadi server process and then restarting them from the akonadi console. pkill akonadi_control pkill akonadiserver Then the server can be started without issue. Not sure how nvidia-drivers would interfere with the dbus communication. Even if it is, why would it no longer interfere with it after restarting it? I've also noticed that on loading up the session, kde has a rough time getting the opengl based compositing / rendering turned on and I often have to manually restart the compositing (alt+shift+f12). Perhaps there is a remote chance it is related.
I'd like to know what NVIDIA is doing differently in their newer drivers, as this bug is not the only one related. I had to downgrade nvidia-drivers because I finally made the jump to grub:2 over the weekend. If not using <=325.xx grub2 hangs in configure phase. There is a bug here but I can't seem to find it at the moment...
So after downgrading the nvidia driver, the first reboot was a success. And so far I do not seem to have any more issue. The same is true for both my Laptop and Desktop computers. But I reebooted just twice and now I am upgrading to KDE 4.11.3. Rebooting a coupe of times with this combination did not yield any errors. The same applies to my Desktop with KDE 4.11.2 and nvidia 325.15. So it really seems to be related to the nvidia driver.... Cheers, Bjoern
x11-drivers/nvidia-drivers-331.20 was unmasked lately and it sneaked in on my system. I guess you can tell how I got aware of this update? Yes, you are right, my Mail client stopped working again. For me this is 100% proof that the nvidia driver is the fault. In the last couple of weeks everything worked flawless. Yesterday I updated my desktop and rebooted today. Downgrading again and masking 331 series drivers did the trick again. Cheers, Bjoern
Things did not get better with KDE SC 4.12.0 but worse. Now I experience the same behavior on KDE 4.12.0 with x11-drivers/nvidia-drivers-319.76 as I had with KDE 4.11.x with x11-drivers/nvidia-drivers-33* I have to remove the error log and then I have to log out and log in again to make "kontact" work. Cheers, Bjoern
Can someone please test with >=331.49?
I don't have any issues with =x11-drivers/nvidia-drivers-331.49 and KDE 4.12.3 Cheers, Bjoern
(In reply to Bjoern Olausson from comment #20) > I don't have any issues with > =x11-drivers/nvidia-drivers-331.49 > and > KDE 4.12.3 > > Cheers, > Bjoern Thanks for testing.
