[kde-linux] Akonadi problems

[Duncan]

lars.koraeus posted on Sat, 17 Apr 2010 10:57:13 +0800 as excerpted:

>> Duncan's hint concerning "mysqld" :  I realised that I had two
>> instances running, one beeing triggered by akonadi, the other one
>> starting from the very beginning from /etc/rc3.d. I removed the last
>> one, but
>>  nothing special happens.
>> 
>> It should hovever become included in general instructions, not to start
>> "mysql" from other applications, if this is crucial to akonadi.
>> 
>> KAddressbook is definitivly _not_ working at all.

> I do hope that the adonadi people will fix this problem. It would be a a
> very bad solution if they think they can hijack other demons. The mysqld
> is not there for KDE sole purpose. If KDE try to stop mysql it is the
> same as never to start KDE at all but use something else. KDE more and
> more seems to become a MS virus. An operating system not care or 
> recognising anything but itself.

This is getting blown /way/ out of proportion.

First, the only reason I used the killall mysqld here, is because I didn't 
have to worry about other packages using it, since it was only for akonadi 
that I installed it in the first place.  Thus, that was the easiest way 
for me to ensure that it got properly stopped along with kde, when kde was 
stopped.  That's all.

It should be noted that killall ordinarily only runs with the rights of 
the user running it.  Thus, if you run a killall command, or a killall 
script, as I suggested, it can normally *ONLY* kill mysqld sessions run by 
the individual user.  It CANNOT kill any system or other user mysqld 
instances, as it won't have the privileges to do so.  Thus, it's only 
mysqld sessions of the individual user running my suggested killall mysqld 
that would be affected, and in the context of my suggestion, it would 
occur as kde shutdown, so presumably as the user was logging out.  In that 
context, most users shouldn't have processes left running anyway (unless 
they happen to have other logins running, text logins or whatever, which I 
might at times, but as I already explained, the only reason I even have 
mysql installed here is for akonadi, so that's not something I need to 
worry about).

So my suggested command couldn't kill the system mysqld anyway, nor other 
user's mysqlds, and if a user is running other mysqld sessions, they 
should know about it and exercise appropriate caution accordingly.  Thus, 
it really IS being blown out of proportion.

Second, the bug I that affected me (and that the killall mysqld was a 
suggested workaround for) is a now known and fixed upstream mysql bug -- 
not a kde or akonadi bug.  Therefore, don't blame kde or akonadi for a bug 
that wasn't even theirs!  That's like blaming kde for a problem with your 
video drivers when all kde's doing is using X and OpenGL methods the way 
they were documented to be run!

Now, it HAS been the opinion of various people I've read the opinions of, 
who've had experience with databases including MySQL, that architecturally 
speaking, using a database, particularly mysql, for this sort of thing, 
isn't the best choice in the world, stability-wise, and I must say I've 
yet to be convinced it's a good thing myself.  I'm /not/ particularly 
looking forward to having kmail dependent on akonadi, and akonadi in turn 
on MySQL, with kde 4.5.  But, one thing they *DID* do is actually take 
their time with the implementation, this time.  They *COULD* have tried 
shoving it out with 4.4, but they deliberately decided to go slower, and 
do only a few less critical things, the address book, and I think one of 
the IM/IRC clients (which I don't use, nor even have installed, so what I 
know on the IM/IRC side is limited to the few bits I've seen being 
discussed, with the accuracy of even that, something I wouldn't vouch 
for).  That bit, at least, is a very GOOD thing, and quite a contrast from 
the way kde4 tried to use plasma before it was even /close/ to ready, 4.0 
thru 4.2 at least, and arguably 4.3 (the plasma desktop of 4.4 is 
/finally/ coming together, IMO, thus, because of its importance to the 
kde4 environment, finally bringing 4.4 to a quality that might have made a 
nice and proper 4.0 release, which is what IMO 4.4 should have been, 4.0).
Going with the akonadi dependency for only less critical stuff for 4.4, 
but yet commonly enough used so distributions and individual system admins 
get the kinks worked out by the time 4.5 comes around and akonadi is used 
for more critical stuff, is actually a reasonably solid plan, FAR more so, 
as I said, than the way plasma was used in 4.0, or even 4.2 and 4.3 which 
kde officially called ready for normal users (something I obviously 
disagree with).  And there's quite a good chance they'll actually pull it 
off, regardless of the doubts I and others still have.  I guess time will 
tell.

There's another aspect of this that can be thrown in as well.  Just as the 
best nepomuk backend thru 4.3 was the Java based Sesame2, with all the 
problems Java itself still has in terms of open source (only now is Iced 
Tea, the freedomware Java implementation, getting reasonably good), with 
the only other option being the incredibly slow Redmond back-end, but 
Virtuoso developed by leaps and bounds to fill the gap, such that with kde 
4.4, it's now the recommended nepomuk backend, and it gets surprisingly 
good ratings for it as well, so, correspondingly, there's a couple in-
development backends for akonadi that by 4.5 may supplant MySQL as the 
recommended akonadi back end.  In fact, Virtuoso itself is one such 
backend under testing, I've read, and given how far it has come in so 
little time, and how well it has worked for nepomuk with 4.4, it could 
well supplant mysql as the recommended akonadi backend for 4.5.  A 
postgresql backend is also in testing, and some folks, particularly those 
who already prefer it to mysql, are already using it.  However, it wasn't 
considered as stable as the mysql backend for 4.4, so mysql remains the 
recommended backend thru 4.4.

Personally, what I'd like to see is the virtuoso backend take off.  IMO 
that's likely to cause the least other problems, because it's not much 
used by anything else basides kde, yet, so can't really affect anything 
else like problems with mysql or postgresql might.  And pretty much anyone 
I've seen an opinion from that knows anything about it, has been quite to 
VERY favorably impressed with how well virtuoso has turned out to work for 
nepomuk with 4.4.  Think about it.  Both nepomuk and akonadi are new 
technologies at about the same stage of development.  Yet there's a LOT of 
folks having issues with akonadi, due to issues with the mysql backend, 
and very few, apparently, having issues with nepomuk, which with the 
virtuoso backend in 4.4, seems to "just work", at least compared to the 
problems people are having with akonadi.  Wouldn't it be nice to have 
/just/ as well a working virtuoso backend for akonadi?  That's what the 
folks working on that backend are hoping.  But it remains to be seen if 
they'll get there, at least for 4.5.

And what's better, kde is already pretty well tied to virtuoso thru 
nepomuk, so if it can be used for both, then some of us will again be able 
to get mysql off our systems once again. =:^)

Meanwhile, back to the current akonadi/mysql issues.  The akonadi-specific 
services stop command (akonadictl stop, IIRC, I've not paid particular 
attention, as I've not had to worry about it since killall mysqld works 
fine for me, no other mysql sessions to worry about) has been posted a 
number of times in several different threads, now.  Presumably, that's 
what folks who have other mysqld sessions running as the same user will 
use to ensure that the akonadi mysqld instance is properly stopped and 
started, if they run into this mysql bug.

Another alternative, since the mysql patch fixing the bug is already 
available, is to simply rebuild mysql with that patch applied.  That's 
what I would have done for any other issue of this sort.  The only reason 
I didn't do it here, is because I saw no reason for that mysqld session to 
still be running when kde was shutdown, since the only reason it was 
running was to service akonadi, and the only thing akonadi is used for is 
kde, at this point.  But had I not already wanted to get the thing to 
properly start and stop along with kde, I'd have grabbed the mysql patch, 
applied it, rebuilt mysql, and would be done with it.  Of course, as I run 
Gentoo, it's likely that rebuilding any old app with some new patch 
applied is less of a big deal to me that it would be to most binary 
distribution users.  While that may be, it can also be pointed out that 
the OP is running Linux from Scratch, so he's compiling from sources too, 
and presumably, it'd not be a big deal for him to apply a mysql patch and 
rebuild it, either.

But all that said, we don't yet even know that the bug of this thread is 
the same one I experienced.  The one I experienced is common, certainly, 
but there's a few other reasonably common ones as well.  And the OP hasn't 
posted enough information to be sure whether it's my bug, one of the other 
common ones, or something else entirely.  And given some of the other 
common issues are user configuration related, so it's very possible this 
one is too, it really *IS* going way off on some wild tangent to be 
talking about kde/akonadi hijacking other daemons.  Not only is the 
problem very likely user config related, not only might it not be the bug 
I had, but even if it is my bug, nobody's really talking about hijacking 
other mysqld sessions, only ensuring that the kde/akonadi mysqld session 
is appropriately terminated in between runs, and even that's only 
necessary due to an upstream msql bug, with a fix already committed 
upstream, so all we're doing is waiting for the new version series updates 
from mysql, and if you don't want to wait, just grab the patch, apply it, 
and rebuild, yourself.

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