Default services enabled

[Tom Lane]

Adam Williamson <awilliam at redhat.com> writes:
> On Tue, 2011-08-23 at 17:28 -0400, Tom Lane wrote:
>> Yeah.  Another way in which socket activation is not transparent is that
>> code might try to determine whether the service is running by seeing
>> whether a connection attempt succeeds.  In such a case, having the
>> service autostart is absolutely *not* the desired outcome.  Both mysql

> 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?

Yes, it is.  Tests with side-effects suck.

> Remember,
> in systemd logic 'service enabled with socket activation, daemon not
> currently running' is effectively an 'on' state, not an 'off' state.

I think that one of the worst aspects of systemd is its assumption that
it can force new world-views upon every other piece of software in the
system :-(.  But anyway, here's an example of why this is a problem:
when we tried to code up socket activation for mysqld, we found there
was no way to make the service case wait for the daemon to actually be
ready to accept connections --- because the only way to test that was to
try a connection, which confused the heck out of systemd when it was
controlling the socket too.  Now maybe what we hit was just a fixable
bug in systemd, but I think it's a fairly fundamental issue.

Another way of saying this is: people are used to being able to check
if a service is up without thereby changing its state.  Consider for
example somebody who has a nagios alert set to check database server
availability every few seconds.  If that probe results in
auto-restarting the database after it crashed, it won't be producing the
desired results, or at least not all of them: yeah, it'll set the server
runnning again, but you'll have no idea from the nagios status that the
server went south at all.  Which is an important part of what people run
that sort of test for.

			regards, tom lane