Default services enabled -> there is no problem with mysqld

Lennart Poettering mzerqung at 0pointer.de
Wed Aug 24 17:36:05 UTC 2011


On Wed, 24.08.11 10:45, Tom Lane (tgl at redhat.com) wrote:

> 
> Reindl Harald <h.reindl at thelounge.net> writes:
> > Am 23.08.2011 23:28, schrieb Tom Lane:
> >> there's no other way for "mysqladmin ping" to work, for example
> 
> > and where is the problem?
> 
> I'm not planning on repeating myself either, but: a database
> *monitoring* tool, as opposed to a vanilla client, needs to know whether
> the database is in fact up.  Autostarting the DB in response to a
> monitoring probe is the wrong behavior for that.

Are you sure it is? The thing is that when using socket activation it is
merely an implementation detail when a service is actually really
started. If you get a response you get a response and that's what you
probably want to monitor. Whether the backing service has been running
all the time or was just started due to your request shouldn't really
matter -- unless of course you actually really want to monitor the
service itself and not just whether it responds. But in that case it's
probably a good idea to ask systemd for the service's status, since it
will provide you with a lot of interesting data, including timestamps
and so on.

So, my claim would be that if you want to monitor whether a service
responds then the backing implementation of it should be asbtract to you
and it doesn't matter whether a service is started, or already running
for that. And if you want to monitor the service itself then it's a good
idea to make use of the monitoring data systemd keeps and hence you
probably should talk to systemd directly in your monitoring tool.

I think it's really important to know what you actually want to monitor,
and then figure out how to do it best.

> I do not really care whether you believe that that's a problem or not;
> it is in my eyes, and as the responsible engineer, I'm not going to
> produce a broken database package.

I do believe socket activation is interesting for SQL servers, but lazy
activation of SQL servers makes little sense.

One should not conflate socket activation with lazy socket
activation. The latter is only interesting for a select few of services
which are very seldom used like CUPS or sshd which are usually only
access less than 1/h.

Socket activation brings a lot of advantages, lazy activation is only
one small one. More interesting are the paralellization or the fact that
we can get rid of explicitly configured dependencies and suchlike.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list