Default services enabled

Simo Sorce simo at redhat.com
Wed Aug 24 15:18:33 UTC 2011


On Wed, 2011-08-24 at 11:08 -0400, Tom Lane wrote:
> Simo Sorce <simo at 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.

I am not sure you can, the only would be to have systemd have some way
to get callbacks from service to know when they are actually ready to
serve. This would make "After" more meaningful. Still wouldn't solve the
problem of a probe ending up causing a database start, I don't think
there is a way to do that if you allow socket-activation.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list