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: > > On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: > > > Why not? > > > > > > If the service is enabled but the daemon not currently running, is it so > > > terrible for a connection test to cause the daemon to start? Remember, > > > in systemd logic 'service enabled with socket activation, daemon not > > > currently running' is effectively an 'on' state, not an 'off' state. If > > > you wanted the database to be 'off' you should have the service > > > disabled, and in that case, the ping test wouldn't cause the daemon to > > > start. > > > > 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. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
