On Fri, 23 Jul 2010 04:12:53 +0200
Lennart Poettering <mzerqung(a)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