Bug 1117086
Summary: | Named (Bind 9) doesn't bind to NIC | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | brian |
Component: | bind | Assignee: | Tomáš Hozza <thozza> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 20 | CC: | chupaka, development, johannbg, lnykryn, msekleta, pemensik, psimerda, s, systemd-maint, thozza, vinschen, vonsch, vpavlin, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | bind-9.9.4-15.P2.fc20 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-07-23 02:59:42 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1119787 |
Description
brian
2014-07-08 02:19:08 UTC
Reassigning to bind. They should either fix unit file and use *only* After=network-online.target or use IP_FREEBIND socket option when trying to bind socket to specific IP address. Your log files list a bunch of possibly related, possibly unrelated problems. 1. plymouthd segfaults This is of course bad, but if this is on a server, you probably don't need plymouth, and might want to remove the package from the system and/or remove rhgb from the kernel command line 2. shorewall cannot start properly, becuase of selinux denial and possibly other issues. Are you sure this isn't screwing up your testing? 3. possible bind issues. Michal's comment deals with that. Please try to separate the issues. Thank you for the response. I know there are several issues showing in the logs. These two servers were built a couple months ago, and have had several issues with them. As I see repeatable / non-stupid items I've been reporting them. Just haven't gotten to everything yet. The selinux issue with shorewall, while I haven't solved, isn't actually preventing the firewall from starting, but I haven't worked out what it is trying to do yet (trying to cat something). Anyway once I isolated the BIND9 named issue, and what the workaround could be, then I thought time to report. The problem appears when upgrading systemd.x86_64 0:208-17.fc20 to systemd.x86_64 0:208-19.fc20 According to changelog, 208-18 contains interesting change: * Tue Jun 17 2014 Zbigniew Jędrzejewski-Szmek <zbyszek.pl> - 208-18 - Make SYSV $network be equivalent to network-online, not network target Probably this patch brokes habitual boot sequence: http://pkgs.fedoraproject.org/cgit/systemd.git/tree/0401-core-sysvcompat-network-should-be-equivalent-to-netw.patch?h=f20 The patch in question only delays the startup of services. It changes the generated services from: After=network.target to: After=network-online.target Wants=network-online.target But network-online.target is After=network.target, so the new requirements are a superset of the old ones. So, as I don't have any SYSV services, something other change affects this? Anyway, manual changing of "After=network.target" to "After=network-online.target" in named.service fixes the situation. It could be timing issue... Even systemd can queue jobs in a different order, etc. You can look at the dependency tree with: systemctl list-dependencies named.service # Wants/Requires systemctl list-dependencies --after named.service # After *** Bug 1119815 has been marked as a duplicate of this bug. *** (In reply to Michal Sekletar from comment #1) > Reassigning to bind. They should either fix unit file and use *only* > After=network-online.target or use IP_FREEBIND socket option when trying to > bind socket to specific IP address. Note that with systemd older than 208-18 everything works just fine ;) I think the changes systemd maintainer did in 208-18 broke things for a lot of services. I'm not going to use IP_FREEBIND as BIND has extensive logic to check which interface has specified address and if there is none, it does not even try to bind to it. Changing this would require non-trivial changes, which are not worth it ATM. However I'll discuss this with upstream if they want/plan to do anything about it. I'll change the network.target to network-online.target for the time being. Fixed in: bind-9.9.5-8.P1.fc22 bind-9.9.5-8.P1.fc21 bind-9.9.4-14.P2.fc20 bind-9.9.4-15.P2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/bind-9.9.4-15.P2.fc20 Package bind-9.9.4-15.P2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing bind-9.9.4-15.P2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8477/bind-9.9.4-15.P2.fc20 then log in and leave karma (feedback). bind-9.9.4-15.P2.fc20 works for me. Thanks, Corinna bind-9.9.4-15.P2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. The fix for this bug gives rise to a cyclic dependency when the glusterd service is also enabled on boot up, see /var/log/message extract below. As a result named doesn't start on boot up, requiring manual intervention on every reboot. Sep 1 08:20:25 test systemd: Found ordering cycle on glusterd.service/start Sep 1 08:20:25 test systemd: Found dependency on named.service/start Sep 1 08:20:25 test systemd: Found dependency on network-online.target/start Sep 1 08:20:25 test systemd: Found dependency on glusterd.service/start Sep 1 08:20:25 test systemd: Breaking ordering cycle by deleting job named.service/start Sep 1 08:20:25 test systemd: Job named.service/start deleted to break ordering cycle starting with glusterd.service/start Reverting the fix returns the system back to normal and named comes up as expected. Not sure if this is something that needs to be tackled in the named or glusterd unit files. Filled new issue on glusterfs project, it seems cyclic dependency is some weirdness in their unit file. Before=network-online is used only by some services configuring network interfaces, NetworkManager-wait-online.service, systemd-networkd-wait-online.service and cloud-init.service. It does make sense on those. On glusterd.service I failed to found a reason for it. 1. https://github.com/gluster/glusterfs/issues/2778 |