Default services enabled

[Lennart Poettering]

On Tue, 23.08.11 18:11, Tom Lane (tgl at redhat.com) wrote:

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

Hmm? sysv services double fork, and exit in the parent. If the parent
exits this is the notification that the listening sockets are all
established. That's how it was handled in sysvinit, and that's how
systemd supports it too with Type=systemd.

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

Checks like this are broken, and have always been broken. They are
insecure (since 3306 is can be bound by everybody).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.