Default services enabled

[Hans de Goede]

Hi,

On 08/24/2011 04:56 PM, Simo Sorce wrote:
> 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.

So maybe we need a socket-activate-once attribute for .service files,
which makes systemd do the socket activation only once, hmm thinking of
it, doesn't it do that already in the form of handing the listening fd over?

So if a service is set to not auto restart the service I would expect
the order would be:

1) systemd starts
2) systemd creates listening socket
3) connection comes in
4) systemd starts foodb, hands overlistening socket
5) foodb crashes
6) db is dead, no one listening to socket.

Right? I guess that unless auto-restart is set for the service, systemd
won't re-create the listening socket and start listening itself again on
step 6. If it does I'm sure that the systemd authors are very reasonable
people and we can tell them that socket activation should not imply
auto-restart on daemon crash / exit (unless explicitly requested).

Regards,

Hans