Comment 11 for bug 326768

Revision history for this message
Will Uther (willu-mailinglists) wrote : Re: mysql thinks it has crashed when it hasn't

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.