Akonadi server will not start

[Duncan]

Frank Weng \(a.k.a. Franklin\) posted on Thu, 20 May 2010 16:06:21 +0800
as excerpted:

> Here is my problem.  I keep getting error messages saying that there are
> old akonadi server error logs.  I deleted them and next time or
> next-next time I get it again.
> 
> However, looking at these two files, I really don't know what the
> problem would be.  It was quite annoying. :(
> 
> Of course I just log out normally (with the lock/logout button) everyday
> I finished my job in the office.

Just so you know, you hijacked Jerry's thread.  That can be kind of 
confusing.  Starting your own is traditional.

Your problem sounds like one I had.

There's a bug in most current versions of MySQL (theres a fix but it's new 
and if there are releases out with it, they are /very/ new, I believe I've 
installed one new version since the patch, which probably has it, but I'm 
not sure about other MySQL version series) having to do with characterset, 
whereby it can only be set once per session.

The problem is that while kde was starting the (per-user) session when kde 
started, it wasn't shutting it down when kde quit, so the next time I 
tried to start kde without rebooting, it would produce this error as it 
tried to set the characterset during the init of the already running MySQL 
session.  IOW, it would run properly the first time I started kde after a 
reboot, but wouldn't run after that because mysql hadn't shut down when I 
shutdown kde, and trying to reinit the existing mysql session on 
subsequent kde startup would produce the error.

Well, I only have mysql installed for kde/akonadi, and it should only be 
running with the kde/akonadi session, so why kde/akonadi could start it 
when it needed it, but not stop it when it didn't, I don't know (tho with 
Kevin's post, it seems it was likely a race condition, with the components 
needed to properly shut it down already down by the time the command was 
issued), but I didn't want the thing running when kde wasn't running 
anyway, so the solution was simple enough.

Similar to what Kevin proposed, if kde/akonadi can't or won't shut down 
its own mysql session, I have to make it shutdown.  Placing a script in 
kde's shutdown dir that simply called "killall mysql" did the trick, as 
that issues a SIGTERM, which allows mysql to cleanup its session and 
terminate normally.

Now, when kde starts, there's no existing session it can try to reinit to 
trigger that bug, so stuff works as it should.

Kevin's suggestion with akonadictl stop is I believe the akonadi specific 
method of my solution, which uses the traditional Unix/Linux signal 
framework, specifically SIGTERM, -15, as issued by killall by default to 
the named process(es), allowing them to terminate gracefully.  (SIGKILL, 
killall -9, would be the last resort method if an app refuses to terminate 
with SIGTERM, but that's a kill by the kernel that doesn't allow an app 
time to clean up its open files and the like, so it's somewhat dangerous, 
but still useful as a last resort at times, but not here.)

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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.