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

[Simo Sorce]

On Fri, 23 Jul 2010 04:12:53 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:

> Well, in your sssd example above the cyclic dependency exists with or
> without systemd. You try to work around this fact in saying "well,
> I simply say that nobody could ever need my services before a certain
> point P in time after boot, and I'll just refuse all services before
> that." However, that is a really broken requirement to make. Why?
> Because it basically means you imply an ordering dependency on your
> socket creation, that is neither expressable with LSB init headers,
> nor with systemd. The dependency you need is: "make sure to start
> services A, B, C *BEFORE* me, and everything else *AFTER* me". Where
> A, B, C is probably something like syslog, and "everything else"
> might be stuff like ssh, policykit, accounts-daemon, the gettys or
> gdm which might need your services because they offer services
> related to non-system users. Neither systemd nor LSB can offer you
> this kind of order dependencies. There is no such thing as expressing
> "before everything but A, B, C". You currently nonetheless require
> this, and that is simply broken. Because already with LSB your init
> script doesn't actually do what you seem to believe it does.

No I don't require any order, I just said that sssd may not be able to
reply with fresh data until the network is up, which is quite different.

Also what I said is that if the sockets are not available, applications
are not stuck, they just don't get any data that sssd would provide and
they go on with their business.

What I was trying to tell however is that it's not all so linear as you
describe it. In some case it will just work out to be that way, in
other it won't, I just want to make sure you realize there are other
valid cases and take them in account.

Simo.

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