[kde-linux] Akonadi problems
1i5t5.duncan at cox.net
Thu Apr 15 11:00:14 UTC 2010
Dr.-Ing. Edgar Alwers posted on Thu, 15 Apr 2010 11:17:03 +0200 as
> since some days, after starting kmail ( this triggers the start of
> akonadi ), I get a serial of five, six error messages popping up,
> "Akonadi resource closed unexpectedly". No idea what is happening, as I
> can get my mail after closing all this message-boxes.
> Question: how can I disable akonadi ? This item is not more included in
> the system-setting box ( why ? ). Or how can I disable services
> selectivly? Using Development ->Akonadi console ?
> I solved the problem at the moment renaming the 3 akonadi exec in
> /opt/kde-4/bin related to mail, but this is force brute.
First, while akonadi is currently (with kde 4.4) only necessary for kab
(kaddressbook), so you only need it working if you're using the
addressbook, know that with 4.5, it'll be needed for kmail as well -- if
akonadi is broken, kmail will be broken.
I'm not particularly looking forward to that day, but what do I know, I'm
just a user...
But that explains why kmail still works (ATM) even when akonadi is broken,
because kmail doesn't (yet) fully require akonadi, it's only required if
you're trying to do stuff with the address book.
It also explains why disabling it really isn't an option any more, and
will certainly be less so with 4.5.
But try opening up the address book with a b0rked akonadi... I did and all
I got was a blank shell -- no content. I guess that's what's likely to
happen with kmail come 4.5 as well...
OK, I happened to have solved my problem here (kde 4.4.2 on gentoo, based
on previous postings you're running LFS, which likely has the same issue
but there may be others as well). But I'm not sure whether your problem
is the same, so I'll describe mine and you can see if it sounds the same,
and try the solution I came up with and see if it works.
Here's what was happening to me. Apparently, current mysql (the database
behind akonadi) has a bug whereby trying to modify its characterset after
it starts fails, and that's what trying to restart akonadi with a
previously running instance of its database does. Also apparently,
there's no automatic mechanism that stops the database when one logs out
of KDE and indeed, of their user entirely. I discovered that there was
still an instance of "mysqld" running as my normal kde user, even when I
was entirely logged out! (I checked this from a different user in a text
Now, here, I normally start kmail with kde, and it runs, normally, as long
as kde's running. Starting kmail of course starts akonadi, which tries to
start the database. But if the database is already running, bam, up comes
the error, and kmail fails to start automatically along with kde.
However, I could start kmail manually and it would start and run -- I just
couldn't access my address book, because as I mentioned, that requires
akonodi now, like kmail itself will with 4.5.
So what was happening, and it took me awhile to figure this out, was the
first time I logged into kde after a reboot, everything worked fine, since
mysqld was started along with akonadi. But as soon as I logged out of kde
and tried to log back in, akonadi would fail to run, due to this bug in
Now as it happens, they know what the mysqld issue is and have patched it
in upstream mysql, but there has apparently not been a version bump since
then, or if there is, Gentoo doesn't have it yet. But anyway, hopefully
by the time kde 4.5 comes out in August, mysqld will be fixed as well.
Meanwhile, other than manually finding and applying the fix, there's
another way to work around the issue. And it happened to be what I
wanted, anyway. Why mysqld continues running by default when I log out of
kde, I don't know, but the easy enough solution was to simply tell it to
shut down when kde was shutting down. Then when kde restarts, and along
with it kmail and akonadi, akonadi starts with a fresh mysqld, and the
problem doesn't happen, because it's not calling a characterset reset on
an already running mysqld session. =:^)
If you like you can test to see if this works, by exiting KDE, starting a
session at the text login, and doing a "psgrep mysqld". If it lists a
number, there's a running mysqld instance. Do a killall mysqld, and
another psgrep mysqld, and see if it went away. (If there's a system
instance running or another user's instance running, killall won't kill
those, only your own, unless you run killall as root, of course.) Then
restart kde, and see if you can run kmail/akonadi without issue. If so,
it's the same bug I had. If not, you have another problem.
The below assumes it's the same bug...
So what I did is setup a script that simply does a "killall mysqld", and
have it run automatically. I could have set it up to run when I started
kde, say from the script I use to start kde, and actually, I'll probably
do that too just to be sure, tho I haven't yet. But what I did was set it
up to run with kde SHUTDOWN (not startup), since the only reason it was
running was for kde apps, kmail, kaddressbook, etc, in the first place,
and all it's doing if it continues to run when I'm logged out of kde is
wasting memory, etc. Why kde doesn't by default shut it down
automatically along with kde, I don't know, but with that script running
on kde shutdown, it does! =:^)
So here's my script:
That's it! I call the script "killmysqld", but call it what you want.
Just be sure to set the executable bit after you save it. I'm not sure the
bash shebang (what they call the first line) is needed, but I use it at
the beginning of all my bash scripts automatically, as that's what my
editor of choice keys on in ordered to give me proper context highlighting.
Now, you can either stick that in the kde shutdown directory itself, or
you can stick it in your user's ~/bin directory or wherever else you
prefer to stick such things, and put a link to it in the shutdown dir. I
have little reason to call the script manually, as I might as well just
run the killall mysqld command itself if I want to do that, so I didn't
want it in my users bindir, and chose to put the script itself in my kde
Now you may be saying, OK, OK, but where's this shutdown dir? Good
question! =:^) I'm not sure what the default is, but here, the dir that's
used is $KDEHOME/shutdown/ (where $KDEHOME is normally ~/.kde or possibly
~/.kde4, depending on distribution). As it happens, kcontrol (now badly
renamed system settings, badly, as it's kcontrol settings, not system
settings, and system settings is way too generic to be generally useful)'s
personal, paths module lists the path for the autostart directory, but not
the shutdown directory. <shrug> In any case, in kcontrol, advanced user
settings, autostart, if you placed it in the correct location the script
should be listed under shutdown. If not, hit the add script button,
browse to the script or type its path in the box, /uncheck/ create as
symlink if you wish, and hit OK. It'll now list as startup. Hit the
combobox and switch that to shutdown. There's no apply button, so quickly
switch to another module and back, to be sure it took. If it's still
listed, it did. If it wasn't listed when you opened the module, you can
now go search your $KDEHOME and see where it put the file if you like, so
you know where the shutdown directory is next time you want to use it.
Now, if that little psgrep/killall/psgrep test above did NOT solve your
problem, the next thing is to figure out exactly what's going wrong. What
stymied me here for awhile is that the akonadi selftest and error dialog
said there were errors in the log, but neither the dialog nor the linked
userbase page it referred to, told me where this log was! I had to figure
that out for myself. As it turns out, this is located under
$XDG_DATA_HOME (which is probably ~/.config/local/share or the like if you
don't export that variable, I have mine customized to
~/config/local/share (I don't like hidden paths!)), in
$XDG_DATA_HOME/akonadi/. You should see a mysql.conf file and an
akonadiserver.error file, plus possibly an akonandiserver.error.old file,
among others. Those error files are the logs.
Post back with anything in those logs, plus the akonadi self-test/
diagnostic, and hopefully we can get it working again.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde-linux