Bug 635081

Moving systemd bugs to f15, since the systemd feature got delayed.

Sounds like a dependency ordering problem in NM. 

If I understand this correctly, then you are asking for NM to be started before bind, not after? Or what is this about?

NM needs to be started before bind because otherwise bind does not have any interface to listen on.

However bind also needs to be started before any other network service, because if it is not they can not resolve their names (since bind also provides local name resolution)

Uh? so you are saying that bind needs to be stated both before and after the network interfaces cam up? That sounds very very broken.

Why isn't bind listening on localhost? I really don't understand this setup.

I'm saying the ordering needs to be

nm (till interfaces are up)
bind
other services that use network

bind can not resolve external adresses without an external link
other services rely on bind for resolving. They need resolving for more than just localhost

(and no bind is not listening only on localhost since it provides resolving for other systems on the lan, not just its own system. So it needs to attach to external interfaces and startup once they are up)

OK, so you request that bind should be ordered after NM? Then let's reassign this to bind, and ask for such a header be added to their LSB header in the init script.

Should-Start: NetworkManager

That line should be enough to ensure that bind gets started after NM if both are enabled.

It's not that simple, bind should be ordered after NM, but *before* any network service. Because network services will try to resolve the addresses they bind to, and that will depend on local dns service on some configurations (like mine)

How does one express the second part in systemd ?

Well, the LSB solution for this is that those services which rely on DNS add a dependency on $named:

http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html

If all services did that properly systemd would have no problem.

So I'd like to claim that this is already an LSB issue, nothing really new in systemd here, except that we rely more on the LSB header info than previous solutions did.

[ That said, the systemd solution for this is that bind would be socket activatable, and if that's not in the cards that people then order themselves properly after nss-lookup.target (which is the systemd name for $named). ]

(In reply to comment #7)
> OK, so you request that bind should be ordered after NM? Then let's reassign
> this to bind, and ask for such a header be added to their LSB header in the
> init script.
> 
> Should-Start: NetworkManager
> 
> That line should be enough to ensure that bind gets started after NM if both
> are enabled.

Hm, that's weird.

NetworkManager has this in it's /etc/init.d/NetworkManager initscript:
...
### BEGIN INIT INFO
# Provides: network_manager $network
...

and BIND has this in it's initscript (/etc/init.d/named):
...
### BEGIN INIT INFO
# Provides: $named
# Required-Start: $local_fs $network $syslog
...

So BIND currently requires $network which is provided by NetworkManager. I don't understand why systemd orders named before NetworkManager. If I understand LSB headers well it shouldn't be needed to add anything to /etc/init.d/named, should it?

(Just FYI:
$ rpm -q NetworkManager bind
NetworkManager-0.8.2-8.git20101117.fc15.x86_64
bind-9.7.3-0.6.rc1.fc15.x86_64
)

Nicolas, so looking at this the order between NM and bind is actually correct and I verified now that systemd parses that correctly. 

So, what is this bug about? Just the ordering between some dns-using services and bind? If so, the title of the bug should be changed at least. And those services in question should be fixed to order themselves correctly after $named resp. nss-lookup.target.

But I don't think there is anything wrong with bind here, so I am reassigning this back to systemd for now, until I understand what you actually are asking for.

Nicolas, please elaborate where exactly you see a bug here?

If you look at the bug you'll see it was opened with systemd-10

I agree that the starts-after-systemd bit seems to have been fixed in rawhide lately (didn't have time to check thoroughly but I haven't had any failure lately)

However I did have a few start-after-other-network-services problems in january, and as far as I know if it seems to work now that's pure luck. I'm pretty sure every network-using service expects name resolution to work as soon as the network is declared ready, and that means starts-after any resolving service if present (bind, dnsmask, etc), but you've confirmed nothing makes sure it's the case right now in systemd

OK, then I'll close this bug for now, assuming that the issues in systemd are fixed. If there are services which lack the reference to $named resp. nss-lookup.target then please file bugs against those packages.