> people would argue that the sysV init solved 99% of the problem
In 15+ years of using linux I never came across a sysv init based system that could reliably restart mysql under all typical production circumstances. Now mysql used (?) to be a close to worst case behaving deamon, but it was also very popular, so if no distributor could handle it correctly with the tools given (and the init scripts tended to be very, very long and complex and hard to debug), how can one argue that it's a 99% solution?
Posted Nov 22, 2012 19:21 UTC (Thu) by hummassa (subscriber, #307)
[Link]
does systemd (and upstart) actually solve this problem?
Crowding out OpenBSD
Posted Nov 22, 2012 19:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
Yep. SystemD can reliably track mysql's state and kill it. Mysql recovery should then take care of unclean shutdowns.
Crowding out OpenBSD
Posted Nov 22, 2012 21:37 UTC (Thu) by paulj (subscriber, #341)
[Link]
How does it reliably track mysqls state btw? What would define a bad state requiring restart?
IME just because a process is running doesn't mean it's actually in a good state. You need some kind of heartbeat protocol. Does systemd implement something like that?
Crowding out OpenBSD
Posted Nov 22, 2012 22:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
[Link]
No, the common problem with mysql is that it doesn't terminate cleanly. Its shutdown scripts can hang for minutes and _still_ leave hanging processes behind. These hanging processes later interfere with the startup.
SystemD nicely solves this problem. Hooking it up with an external heartbeat monitor should also be quite easy.
Crowding out OpenBSD
Posted Nov 22, 2012 23:25 UTC (Thu) by cortana (subscriber, #24596)
[Link]
systemd can be configured to require that a service regularly notifies that it is still up, or else it'll be killed & restarted. See http://0pointer.de/blog/projects/watchdog.html for the details.