On 20:17:14 Wednesday 24 August 2011 Adam Williamson wrote:
On Wed, 2011-08-24 at 09:06 -0400, Simo Sorce wrote:
> > 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.
Sure, and I agree with you that socket activation may not be a great
idea for a constantly-used database. I should've made it clearer that I
was engaging with the generic argument - 'socket activation makes it
tough to check the state of services by pinging them' - not the specific
example - 'socket activation makes it tough to check the state of MySQL
by pinging it'. As far as I was concerned, MySQL was just an arbitrary
example chosen by the OP.
I want to add one more POV - not every database is constantly-used. Example
usage is Amarok using mysql database and I really want mysql to not be started
until I start Amarok. Not that this is very common usage scenario but still I
know at least one guy using Amarok with mysql :).
Alexander Kurtakov