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.
