[mythtv-users] Ordering of mysql and mythbackend shutdowns

[f-myth-users@media.mit.edu]

I've just noticed that, when rebooting the master backend machine,
mysql gets shut down before the backend (because, of course, "mysql"
sorts before "mythbackend" and typically they're both started/stopped
w/the same two-digit priority in the rc scripts).  This causes the
backend (if it's logging verbosely, which mine is) to emit a bunch of
lines about being unable to talk to the database just before it dies.
(Actually, the complaints seem to be coming from a different pid than
the backend while it's running; I'm not sure if it's getting respawned
for an instant or what.)

I don't care about the warning per se, but I don't know if, when it
gets the termination signal, the backend tries to do any sort of
cleanup or housekeeping which requires the database.  If it does,
I suppose I should arrange for the database to come down afterwards.
Does this ever matter?  I can't seem to find anything useful about
this in searching various archives; I'm guessing that the backend
never has anything important pending that it wouldn't just write to
the database immediately without caching, but I don't know.

(I also don't know what would happen to any in-progress jobs such as
commflagging; I'm assuming they'd just be restarted upon boot 'cause
they wouldn't have been deleted from the job queue.)

This is in 18.1, but I suppose it'd be good to know for svn, too.