[Bug 326768] Re: mysql thinks it has crashed when it hasn't

[Will Uther]

I thought I'd list what I discovered when originally looking at this
bug.  Much of this is mythtv specific.  I'm currently of the opinion
that there are issues in both mythtv and mysql, with the mythtv strange
behaviour tickling a mysql issue.

On a problematic boot, mysql starts normally.  This means that the
mysqld_safe script is run.  It starts the mysql daemon then waits for
the daemon to stop.  If the daemon stops normally (the pid file has been
removed) then mysqld_safe exits.  If the daemon didn't stop normally
then mysqld_safe kills any remaining instances of mysqld running, before
restarting the daemon.

mythbackend then starts.  During startup, mythbackend does a reschedule
of its recordings (i.e. it goes through the list of programs to be
recorded and the epg and decides which ones to record with which tuner).

At some point around this time, mysqld_safe is detecting that the mysql
daemon has stopped.  It is then, as noted above, killing all remaining
mysql daemon processes, before starting a fresh one.  My understanding
is that on my default desktop jaunty install I should only ever have one
mysql daemon running at once (and a quick ps reveals that is what I
currently have).  If you look at the logs above, you'll see that
mysqld_safe is detecting one mysql daemon running after it has already
decided that one has failed.  This is what I meant by the bug report
title, "mysql thinks it has crashed when it hasn't".  This seems to be a
problem with a false detection of a crash causing the cleanup mechanism
to actually kill the mysqld process.

When the mysqld process is killed in this way during a mythbackend
reschedule, mythbackend fails to schedule any recordings.  Once the
database restarts, mythbackend can still access the database - e.g. you
can see the epg, and you see the list of programs you've ask to be
recorded.  If you do anything that causes mythbackend to re-schedule
recordings (e.g. change anything in the list of programs to be recorded
- you can even change it back after the reschedule), then mythbackend
will connect to the db, reschedule correctly and everything will be
fine.

This is a little bit weird in that restarting mythbackend later doesn't
cause mysql to restart again.  It only seems to restart once.  If there
was a major problem with mythbackend then I would expect it to show up
every time mythbackend is restarted.

It also doesn't seem to be a race condition (which was suggested by the
fact that it only happens the first time).  If I put a `sleep 10` at the
start of the mythbackend init script it doesn't help.


** Summary changed:

- mysql thinks it has crashed when it hasn't
+ mysqld_safe thinks mysqld has crashed when it hasn't

-- 
mysqld_safe thinks mysqld has crashed when it hasn't
https://bugs.launchpad.net/bugs/326768
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mysql-dfsg-5.0 in ubuntu.