Default services enabled

[Jesse Keating]

On Aug 24, 2011, at 10:05 AM, Adam Williamson wrote:
> 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.
> 
> 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?


Some of the argument here is that it is difficult to do this from a remote host.  You'd have to engage in remote execution of software, e.g. using nagios nrpe to remotely (from the nagios system) execute commands on the database system to call systemd to check the status of the db.

This is a shift from previous environments where you could just poke at the network socket from the nagios system and parse the reply.

- jlk