Bug 230247 - Akonadi::Control::start() does not work
Summary: Akonadi::Control::start() does not work
Status: RESOLVED WORKSFORME
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: libakonadi (show other bugs)
Version: 4.5
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: Volker Krause
URL:
Keywords:
: 233113 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-10 21:59 UTC by Silver Salonen
Modified: 2011-03-06 09:20 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silver Salonen 2010-03-10 21:59:06 UTC
Version:            (using KDE 4.4.1)
Installed from:    openSUSE RPMs

Sometimes KMail exits when Akonadi is not running and KMail thinks it could not start Akonadi correctly. It happens only when Akonadi reports some errors (which I wouldn't understand), but it runs fine after that anyway. When I just start KMail again, it starts OK and doesn't exit anymore (I guess it's because it finds Akonadi running OK this time).

The last messages before exit:

kmail(10331)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on  "local:/tmp/ksocket-elika/kmaila10331.slave-socket"
kmail(10331)/libakonadi Akonadi::Control::Private::exec: Could not start/stop Akonadi! 
Detaching after fork from child process 10417.
Detaching after fork from child process 10419.
Detaching after fork from child process 10420.
kmail(10331) main: Unable to start Akonadi server, exit application 
kmail(10331)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
[Thread 0xaf403b70 (LWP 10407) exited]
[Thread 0xb13e3b70 (LWP 10334) exited]

Program exited with code 01
Comment 1 Björn Ruberg 2010-04-05 23:24:52 UTC

*** This bug has been marked as a duplicate of bug 218278 ***
Comment 2 Björn Ruberg 2010-04-05 23:26:29 UTC
*** Bug 233113 has been marked as a duplicate of this bug. ***
Comment 3 Silver Salonen 2010-04-06 07:33:19 UTC
Is it really the same as 218278, because in my case KMail didn't crash, but just exited.
Comment 4 Björn Ruberg 2010-04-06 10:56:38 UTC
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.
Comment 5 Silver Salonen 2010-04-06 11:02:37 UTC
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?
Comment 6 Maciej Mrozowski 2010-08-04 18:20:17 UTC
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.
Comment 7 Vasileios P. Lourdas 2010-08-23 11:11:53 UTC
(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.
Comment 8 Maciej Mrozowski 2010-08-31 16:52:23 UTC
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...
Comment 9 Maciej Mrozowski 2010-08-31 16:57:29 UTC
Please reassign to akonadi (kdepimlibs) devs. Not kmail bug.
Comment 10 Lamarque V. Souza 2010-09-07 19:06:53 UTC
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.
Comment 11 Maciej Mrozowski 2010-09-07 23:08:43 UTC
(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.
Comment 12 Lamarque V. Souza 2010-09-07 23:14:48 UTC
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.
Comment 13 Maciej Mrozowski 2010-09-08 00:39:25 UTC
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.
Comment 14 Lamarque V. Souza 2010-09-08 00:57:09 UTC
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.
Comment 15 Silver Salonen 2010-09-08 07:42:10 UTC
$ 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.
Comment 16 Lamarque V. Souza 2010-09-08 17:33:06 UTC
(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.
Comment 17 Silver Salonen 2010-09-08 19:32:53 UTC
$ kde4-config --path data
/home/silver/.kde4/share/apps/:/usr/share/kde4/apps/:/etc/kde4/share/apps/
Comment 18 Maciej Mrozowski 2010-10-05 20:29:01 UTC
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.
Comment 19 Lamarque V. Souza 2010-10-06 01:14:48 UTC
(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.
Comment 20 Lamarque V. Souza 2010-10-06 01:58:03 UTC
(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.
Comment 21 Maciej Mrozowski 2010-10-06 07:18:30 UTC
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..
Comment 22 Lamarque V. Souza 2010-10-06 16:13:45 UTC
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.
Comment 23 Maciej Mrozowski 2010-10-07 00:44:31 UTC
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.
Comment 24 Volker Krause 2010-12-28 15:55:13 UTC
KMail in 4.6 does not use Akonadi::Control::start() anymore (nor does any other KDE PIM app).
Comment 25 Vasileios P. Lourdas 2011-03-06 09:20:28 UTC
Just upgraded to KDE 4.6.1 and the same issue has again appeared. My KMail version is 4.4.10.