Bug 230247

*** This bug has been marked as a duplicate of bug 218278 ***

*** Bug 233113 has been marked as a duplicate of this bug. ***

Is it really the same as 218278, because in my case KMail didn't crash, but just exited.

Well, there is obviously a problem with kmail when akonadi crashes. When bug #218278 is fixed this one is probably too. So I see no advantage in keeping them divided.

Akonadi doesn't crash in my case (at least I see it running after KMail exits). Isn't there anything for KMail to do when it cannot interact with Akonadi, eg. wait a bit, keep going without it, try to start it again, etc?

Here's my akonadi log from kde sc 4.5 (so kdepimlibs 4.5), kdepim 4.4 and akonadi 1.4.0
Obviously akonadi doesn't crash, but client app requesting it is wrongly notified abutt akonadi status when it's started on-demand for the first time.

Akonadi Server Self-Test Report
===============================

Test 1:  SUCCESS
--------

Database driver found.
Details: The QtSQL driver 'QSQLITE' is required by your current Akonadi server configuration and was found on your system.

File content of '/home/maciek/.config/akonadi/akonadiserverrc':
[%General]
Driver=QSQLITE
SizeThreshold=4096
ExternalPayload=false

[QMYSQL]
StartServer=true
ServerPath=/usr/sbin/mysqld
Name=akonadi
Host=
User=
Password=
Options="UNIX_SOCKET=/home/maciek/.local/share/akonadi/db_misc/mysql.socket"

[QPSQL]
Name=akonadi
Host=
User=akonadi
Password=akonadi
Port=5432
Options=
StartServer=false

[Debug]
Tracer=null

[QSQLITE]
Name=/home/maciek/.local/share/akonadi/akonadi.db


Test 2:  SUCCESS
--------

Akonadi is not running as root
Details: Akonadi is not running as a root/administrator user, which is the recommended setup for a secure system.

Test 3:  SKIP
--------

MySQL server executable not tested.
Details: The current configuration does not require an internal MySQL server.

Test 4:  SKIP
--------

MySQL server error log not tested.
Details: The current configuration does not require an internal MySQL server.

Test 5:  SKIP
--------

MySQL server configuration not tested.
Details: The current configuration does not require an internal MySQL server.

Test 6:  SUCCESS
--------

akonadictl found and usable
Details: The program '/usr/bin/akonadictl' to control the Akonadi server was found and could be executed successfully.
Result:
Akonadi 1.4.0


Test 7:  SUCCESS
--------

Akonadi control process registered at D-Bus.
Details: The Akonadi control process is registered at D-Bus which typically indicates it is operational.

Test 8:  SUCCESS
--------

Akonadi server process registered at D-Bus.
Details: The Akonadi server process is registered at D-Bus which typically indicates it is operational.

Test 9:  SUCCESS
--------

Nepomuk search service registered at D-Bus.
Details: The Nepomuk search service is registered at D-Bus which typically indicates it is operational.

Test 10:  SUCCESS
--------

Nepomuk search service uses an appropriate backend. 
Details: The Nepomuk search service uses one of the recommended backends.

Test 11:  SKIP
--------

Protocol version check not possible.
Details: Without a connection to the server it is not possible to check if the protocol version meets the requirements.

Test 12:  SUCCESS
--------

Resource agents found.
Details: At least one resource agent has been found.

Directory listing of '/usr/share/akonadi/agents':
birthdaysresource.desktop
contactsresource.desktop
icalresource.desktop
imapresource.desktop
kabcresource.desktop
kcalresource.desktop
knutresource.desktop
kolabproxyresource.desktop
localbookmarksresource.desktop
maildirresource.desktop
maildispatcheragent.desktop
mboxresource.desktop
microblog.desktop
mtdummyresource.desktop
nepomukcalendarfeeder.desktop
nepomukcontactfeeder.desktop
nepomuktagresource.desktop
nntpresource.desktop
notesresource.desktop
pop3resource.desktop
vcarddirresource.desktop
vcardresource.desktop
Directory listing of '/usr/share/akonadi/agents':
birthdaysresource.desktop
contactsresource.desktop
icalresource.desktop
imapresource.desktop
kabcresource.desktop
kcalresource.desktop
knutresource.desktop
kolabproxyresource.desktop
localbookmarksresource.desktop
maildirresource.desktop
maildispatcheragent.desktop
mboxresource.desktop
microblog.desktop
mtdummyresource.desktop
nepomukcalendarfeeder.desktop
nepomukcontactfeeder.desktop
nepomuktagresource.desktop
nntpresource.desktop
notesresource.desktop
pop3resource.desktop
vcarddirresource.desktop
vcardresource.desktop

Environment variable XDG_DATA_DIRS is set to '/usr/share:/usr/local/share:/usr/share'

Test 13:  SUCCESS
--------

No current Akonadi server error log found.
Details: The Akonadi server did not report any errors during its current startup.

Test 14:  SUCCESS
--------

No previous Akonadi server error log found.
Details: The Akonadi server did not report any errors during its previous startup.

Test 15:  SUCCESS
--------

No current Akonadi control error log found.
Details: The Akonadi control process did not report any errors during its current startup.

Test 16:  SUCCESS
--------

No previous Akonadi control error log found.
Details: The Akonadi control process did not report any errors during its previous startup.

(In reply to comment #6)
> Here's my akonadi log from kde sc 4.5 (so kdepimlibs 4.5), kdepim 4.4 and
> akonadi 1.4.0
> Obviously akonadi doesn't crash, but client app requesting it is wrongly
> notified abutt akonadi status when it's started on-demand for the first time.

I think that's maybe the source of the problem. In my Gentoo box, I run 4.5.0 with kdepim-4.4.5 and I get this behavior. If I start akonadi from a terminal (akonadictl start) and then start KMail, no error occurs.

I've narrowed it down a bit - what's broken is Akonadi::Control::start() in kdepimlibs 4.5.

From 4.4 to 4.5, some code was moved to ServerManager (asynchroneous startup/shutdown), and while ServerManager works well, imho that event loop in Akonadi::Control is apparently unable to intercept stateChanged(State) from ServerManager in time or sth like this.

Anyway all this handling looks way too complicated. Really Akonadi doesn't offer native synchroneous (blocking) method for server startup and it needs to be worked around with fake delays (timers) and event listeners? I mean, come on...

Please reassign to akonadi (kdepimlibs) devs. Not kmail bug.

I use Gentoo and used to have this problem until KDE SC 4.5.0, with KDE SC 4.5.1 it is working ok after some changes I had to make because I use kdeprefix USE flag, which installs KDE in a separated directory (/usr/kde/4.5). There is some time that Gentoo does not support kdeprefix but I decided to keep using it.

One thing I noticed when I had this problem is that /usr/kde/4.4/share (I use kmail-4.4.5) wasn't in XDG_DATA_DIRS because /usr/kde/4.5/bin/startkde overrides the settings in /etc/env.d/ by removing all /usr/kde/*/share directories and adding only /usr/kde/4.5/share. After I changed startkde to add /usr/kde/4.4/share it worked as expected. OpenSuse 11.3 use /usr/share/kde4 to store the KDE's share directory and by what I saw in /usr/bin/startkde and /etc/profile.d/xdg-environment.sh it does not add /usr/share/kde4 to XDG_DATA_DIRS, maybe this is the cause of the problem in OpenSuse. I cannot fully test this because I do not have OpenSuse installed here.

Another thing I noticed is that plasma-desktop runs akonadi-server at login, so when I call kmail akonadi-server is already running and kmail does not need to call Akonadi::Control::start(). Even if I stop akonadi-server (akonadictl stop) and start kmail, kmail is able to start akonadi and run ok here. The only thing I had to do is configure XDG_DATA_DIRS correctly in startkde. It is very important that XDG_DATA_DIRS is correctly configured in startkde or all KDE programs use a misconfigured XDG_DATA_DIRS to call programs, which affects Akonadi::Control::start(). I created a .desktop file in ~/.config/autostart to call env command to save the environment variables to a file and then I noticed XDG_DATA_DIRS wasn't configured correctly. In konsole XDG_DATA_DIRS was configured correctly because it always run the /etc/profile script that restores the correct configuration.

(In reply to comment #10)
> I use Gentoo and used to have this problem until KDE SC 4.5.0, with KDE SC
> 4.5.1 it is working ok after some changes I had to make because I use kdeprefix
> [...]

Please do *not* hijack this bug with your kdeprefix originated problems. kdeprefix is unsupported and it's for a reason - I know as I was one of people implementing it and the one who realized it's not going to work.

This bug is about Akonadi::Control::start() method always returning false. And it's by no means XDG_DATA_DIRS related. (I don't have to mention that Akonadi server starts successfully here). So, please do not hijack this bug with unrelated comments. Thanks.

I do not have problem with akonadi, it is working perfectly here. I just wanted to help. If you do not want help, so be it.

We must be living in different realities. In mine, I've already helped as I've narrowed it down to Akonadi::Control::start() and you're not helping to fix this bug so please stop. Thanks.

I said to verify if XDG_DATA_DIRS is correctly set, that was the problem I had here and by what I saw OpenSuse could also have this problem because they also stores the KDE's share dir in a different directory as kdeprefix does. I only mentioned kdeprefix because of that. Today I do not have this problem anymore, I can close akonadi, start kmail and Akonadi::Control::start() starts akonadi correctly and kmail works.

When I had this problem plama-desktop started akonadi-server at login but since XDG_DATA_DIRS was incorrectly set it could not found some files but it run without those files. When kmail started it carried akonadi for those missing files and since nothing was sent kmail run Akonadi::Control::start(), but since akonadi was already running it did not work. Even if I stopped akonadi and run kmail Akonadi::Control::start() did not work because XDG_DATA_DIRS was incorrectly set in kmail's environment.

Why don't you verifiy if XDG_DATA_DIRS is correctly set. If it is then this is not the problem, but it is not then problem solved, simple. You do not need to be rude and chase people from here just becase they thing different from you.

$ echo $XDG_DATA_DIRS
/usr/share:/etc/opt/kde3/share:/opt/kde3/share

It seems that KDE4 share directory on openSUSE is /usr/share/kde4.

(In reply to comment #15)
> $ echo $XDG_DATA_DIRS
> /usr/share:/etc/opt/kde3/share:/opt/kde3/share
> 
> It seems that KDE4 share directory on openSUSE is /usr/share/kde4.

What does the command below return?

kde4-config --path data

If /usr/share/kde4 is listed then XDG_DATA_DIRS is not the problem.

$ kde4-config --path data
/home/silver/.kde4/share/apps/:/usr/share/kde4/apps/:/etc/kde4/share/apps/

I already asked you to stop with XDG_ nonsense, it's completely unrelated to this issue.

Now.

Actually Akonadi::Control::start() may even work well (return proper status), but... akonadi self-test dialog box is displayed *nevertheless*, and when it's clicked it terminates application so end effect is identical.

(In reply to comment #18)
> I already asked you to stop with XDG_ nonsense, it's completely unrelated to
> this issue.


 
> Now.
> 
> Actually Akonadi::Control::start() may even work well (return proper status),
> but... akonadi self-test dialog box is displayed *nevertheless*, and when it's
> clicked it terminates application so end effect is identical.

(In reply to comment #18)
> I already asked you to stop with XDG_ nonsense, it's completely unrelated to
> this issue.

And I already suggested you to be more polite here. XDG_* variables exists for a reason, KDE let users to install SC in different prefixes, even us KDE developers use that feature for testing different versions. When installed in non-standard prefix someone must set XDG_* variables accordingly to avoid problems, so it makes perfect sense to verify if XDG_* variables are correctly set. It is easy to check it out, you being upset by that is what does not make sense. I agree that this particular problem is not related to XDG_*, thanks to Silver Salonen for having the patience to help me with that. Fortunately for me setting XDG_DATA_DRIS solved my problem.
 
> Now.
> 
> Actually Akonadi::Control::start() may even work well (return proper status),
> but... akonadi self-test dialog box is displayed *nevertheless*, and when it's
> clicked it terminates application so end effect is identical.

Well, I do not have this problem anymore and cannot reproduce what you described above.

So you were having other issue not related to this bug like I said already and I asked you to stop. Thank you for taking your time to derail this bug.

It's no wonder Akonadi devs are not interested in fixing this issue when they're being provided with inaccurate or misleading information here and there and sometimes they need to skip whole bunch of pointless discussion only to cherry-pick one relevant comment...

which is:

Actually Akonadi::Control::start() may even work well (return proper status),
but... akonadi self-test dialog box is displayed *nevertheless*, and when it's
clicked it terminates application so end effect is identical as Akonadi::Control::start() returned false despite the fact Akonadi started successfully..

Maybe, but XDG_DATA_DIRS is very easy to test, if you had used just a few minutes to do it and a little more openness in your mind you could have checked it out of instead just dumping a suggestion with no real reason. I used to have a problem with exactly same symptoms, correctly setting XDG_DATA_DIRS solved it for me. I could have just forgotten about this bug, since I do not have it anymore, it is not my problem anymore, but instead I tried to help, because that is the attitude we should have when someone needs help and we have something that may help, and you just dumped my suggestion without even trying to check it out. With attitude like yours why anybody here would step up to help? Just do be dumped too?
 
> which is:
> 
> Actually Akonadi::Control::start() may even work well (return proper status),
> but... akonadi self-test dialog box is displayed *nevertheless*, and when it's
> clicked it terminates application so end effect is identical as
> Akonadi::Control::start() returned false despite the fact Akonadi started
> successfully..

Ok, so let's try your comment. I really do not understand how that could happen. Me and several other people do not have this problem (I used to, but not anymore as I said), if things happen the way you said everybody should have this problem. How did you find that out? I looked at akonadi, akonadi-server and kmail's source code yesterday but I do not see how what you described could happen for some people and not for everybody. Maybe it is a suttle corruption in akonadi's database, that would explain why not everybody have this problem. You can try deleting the database and restarting everything again.

Take a look at akonadi log I posted here some time ago (and what other people said as well before) - Akonadi *doesn't* crash or report *any* issue - yet self-test dialog appears - I suppose it rules out database corruptions and XDG_ issues right from the start, do you agree?

The source you're interested in is in kdepimlibs as it's where Akonadi server control library is implemented (akonadi server itself just provides DBus API). Please digg there.

As for why it does not happen for everyone - if I knew that it would be probably fixed already. Possible answers: race conditions or improperly or too optimistic timeouts set - so depending on machine performance. Akonadi::Control class uses timers and other workarounds to simulate synchroneous (blocking) startup/shutdown (which is otherwise natively event based).

This bug has been voted by a few people and it has a few duplicates so it's quite safe to assume issue is present.

KMail in 4.6 does not use Akonadi::Control::start() anymore (nor does any other KDE PIM app).

Just upgraded to KDE 4.6.1 and the same issue has again appeared. My KMail version is 4.4.10.