[HEADS-UP] systemd for F14 - the next steps

[Simo Sorce]

On Thu, 22 Jul 2010 18:35:22 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> On Thu, 22.07.10 11:29, Simo Sorce (ssorce at redhat.com) wrote:
> 
> > > they hence would have needed to be started one after the other, so
> > > that every service using another services can be sure it can talk
> > > to the one it needs. I mean, how awesome is that? We can
> > > completely remove *any* kind of serialization from daemon startup.
> > 
> > how do you deal with circular dependencies in this case?
> > I mean what will happen ? Will all services just deadlock?
> > Malfunction ? Anything that guarantees correct initialization and
> > behavior ?
> 
> If a service A uses functionality provided by a service B which in
> turn uses functionality provided by A then things willbreak regardless
> whether systemd is used or not.

This is not true.
SSSD is an example of that.

The nss_sss and pam_sss clients know to immediately give up if the
sockets are not there because that means that sssd is not up yet.

Once sssd is up they will start working. This way if a service comes up
1st in the system and do some stupid enumeration getpwent() it will not
block with timeouts or what not. After all if it is a system service
and does an enumeration so early it is certainly not interested in
non-system users.

If I were to use socket activation instead that service would bring
sssd up unnecessarily early, before the network is up. This in turn
will cause sssd to go in offline mode and have a 30 sec delay before it
tries again to go online, failing any authentication for users that are
not already cached (with credentials cached).

Now this will probably mitigated by the fact that we monitor network
interfaces in newer versions and will try to get online earlier if an
interface suddenly appears, but I hope you get the point.

> Cyclic dependencies cause deadlocks. Introducing systemd has little
> effect on that. It won't make the situation worse, and it won't make
> itmuch better either.

I beg to differ, you are changing how dependencies are handled, and can
*cause* cyclic dependencies because of how you make socket activation
work.

> Or in other words: If somebody writes a syslog implementation that
> writes its logged data to mysql, ignoring that mysql actually itself
> logs to syslog, then it is his own fault, and this simply doesn't
> work, regardless if syslog or mysql is socket-activated or not, or
> whether systemd is used at all. It cannot work, already on a
> theoretical level.

This is not the case, although also in SSSD we have code to prevent
libraries from deadlocking us when they try to to getpw* calls (like
libdbus).

> Or in even other words: this is a theoretical problem, not a practical
> one, and orthogonal to the problem set systemd tries to solve.

I wish it were true.
It is your attitude to ignore this kind of problems and just mark
them as impossible or unimportant that really scares me. I look back
and I see some of the pulseaudio failures all over again .oO("It's your
kernel driver that sucks, I don't care, pulseaudio works fine with
mine, so I won't even attempt a workaround").

Ignoring scenarios just because they are complex to deal with does not
make them go away. Software will not have the luxury to ignore them.

When it is audio I may not care, when it is the init system I do.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York