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. _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
