Default services enabled

[Lennart Poettering]

On Wed, 24.08.11 20:22, Alexander Kurtakov (akurtako at redhat.com) wrote:

> 
> 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 :).

Please, don't conflate general socket activation with lazy socket
activation. The former is the generic technology that provides us with a
lot of advantages like robustness, parallelization, simplicity because
deps don't need to be configured explicitly anymore. The latter is
something that is useful for very few selected services, like CUPS and
sshd which are used very seldom (i.e. less often than 1/h in 90% of the
cases).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.