[kde-linux] Akonadi problems

[Duncan]

Dr.-Ing. Edgar Alwers posted on Thu, 15 Apr 2010 11:17:03 +0200 as
excerpted:

> 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 
login.)

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 
mysqld.

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:

#!/bin/bash
killall mysqld

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 
shutdown dir.

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