On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote: > Simo Sorce <s...@redhat.com> writes: > > On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: > >> On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: > >>> It generally is a bad idea to automatically restart a database based on > >>> a random connection. There many reasons why you may have stopped the db > >>> (or it may have stopped itself) and requires inspection before > >>> attempting a new restart. Having to battle with socket activation while > >>> in a critical situation is not a good idea. > > >> You'd have the same problem with any init system that supports automatic > >> service restarting. You can easily disable the service via systemctl. > > > You can do that if you are doing a planned outage. But not for unplanned > > ones. > > > I am not saying automatic restarts should never be employed, only that > > not all software should be automatically restarted. I think databases > > shouldn't in most cases. But that's just my opinion on the specific > > case. That doesn't mean socket-activation shouldn't be employed in other > > cases. > > FWIW, I do think that there may be use-cases for socket activation of a > database. I'd like to support the option ... the problem is to do so > without breaking existing, expected behaviors.
It was noted up-thread that systemd can tell you whether the underlying daemon is running or not, though I guess that doesn't tell you whether it's entirely in a functional state. You could do a two-stage thing: check with systemd whether the daemon is running, and ping it if so? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
