Bug 847452
Summary: | named and dhcpd startup after NIC initialized | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gene Czarcinski <gczarcinski> |
Component: | NetworkManager | Assignee: | Dan Williams <dcbw> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | danw, dcbw, psimerda |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-13 14:07:55 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gene Czarcinski
2012-08-11 14:58:38 UTC
This is a problem in bind. What you are requesting is to let NetworkManager work around a bug in bind.
> My request: add code to NetworkManager to start (restart?) named, dhcpd, and
> perhaps others after interface initialization is complete.
NetworkManager should definitely *not* include code to start/restart systemd-managed services. But it has support for dispatcher.d scripts that allows you
to add workarounds to the particular packages.
Is there anything you miss in dispatcher.d support? Otherwise I'll be closing this bug report.
I looked once again at the solution proposed in bug 837173 and it looks like it's something that always worked and the only problem was with systemd's path change. Closing. Sorry, but the solution proposed for bug 837173 fixes nothing! Please read my comments in 837173 If there are dependencies between things here, there are two approaches: 1) make the service that depends on networking more aware of it's real dependencies. That means, if named is configured to listen on some specific interface, or some specific IP address, then the named service should really be waiting for that address or interface to come up, not just "networking" to start. But that entails modifying services and their startup scripts. 2) enable the "NetworkManager-wait-online.service" systemd service, which will block startup until the earlier of (1) at least one network interface has started, and (2) 30 seconds have passed. NetworkManager provides the networking service, but in systemd land that just means networking has started, that doesn't mean that any interface has an IP address yet. That's what NM-wait-online is for. And as (2) will not restart services on network configuration changes, you have to: 2b) Put a restarer into /etc/NetworkManager/dispatcher.d > Sorry, but the solution proposed for bug 837173 fixes nothing! Please read
> my comments in 837173
You have opened a bug report on NetworkManager. I believe NetworkManager provides all necessary tools for other packages to very easily work around
their limitations with a simple script dropped in /etc/NetworkManager/dispatcher.d.
Dan's comment describes a way to delay starting of services until NM has acquired his first connection.
The NetworkManager package won't carry a list of services that can't cope with network changes. The maintainers of these services currently bundle scripts for dispatcher.d and that do exactly what you requested.
If there is anything else needed in NetworkManager to support these use cases, please let us know.
This is a useless "fight" and I accept that the problem is in bind. Personally, I gave up on bind/named and replaced bind/dhcpd with dnsmasq which is smart enought to monitor the intefaces and recover when their initialization is complete. Those who argued that named should be "fixed" are correct. I guess I was looking for a "quick fix" but that just was not a reasonable thing to do. NetworkManager should go and continue doing the good work such as support for bridged interfaces. ;) > Those who argued that named should be "fixed" are correct. I guess I was > looking for a "quick fix" but that just was not a reasonable thing to do. The original bug report was about a problem with the quick fix. It didn't work because of wrong systemctl path. > NetworkManager should go and continue doing the good work such as support > for bridged interfaces. ;) On the way :). |