Description of problem: When named is being started in rawhide (Fedora 19), it starts correctly, but systemd still terminates it after timeout: # service named start Redirecting to /bin/systemctl start named.service Job for named.service failed. See 'systemctl status named.service' and 'journalctl -xn' for details. /var/log/messages: Mar 12 16:16:21 vm-088 named[27951]: all zones loaded Mar 12 16:16:21 vm-088 systemd[1]: PID file /run/named/named.pid not readable (yet?) after start. Mar 12 16:16:21 vm-088 named[27951]: running Mar 12 16:16:45 vm-088 ntpd[25427]: 0.0.0.0 0512 02 freq_set ntpd 0.000 PPM Mar 12 16:16:45 vm-088 ntpd[25427]: 0.0.0.0 0515 05 clock_sync Mar 12 16:17:51 vm-088 systemd[1]: named.service operation timed out. Terminating. Mar 12 16:17:51 vm-088 named[27951]: shutting down Mar 12 16:17:51 vm-088 named[27951]: stopping command channel on 127.0.0.1#953 Mar 12 16:17:51 vm-088 named[27951]: stopping command channel on ::1#953 Mar 12 16:17:51 vm-088 named[27951]: no longer listening on ::#53 Mar 12 16:17:51 vm-088 named[27951]: no longer listening on 127.0.0.1#53 Mar 12 16:17:51 vm-088 named[27951]: no longer listening on 10.34.47.88#53 Mar 12 16:17:51 vm-088 named[27951]: exiting Mar 12 16:17:51 vm-088 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). Mar 12 16:17:51 vm-088 systemd[1]: Unit named.service entered failed state Version-Release number of selected component (if applicable): bind-9.9.2-10.P1.fc19.x86_64 How reproducible: Steps to Reproduce: 1. Create a basic named.conf 2. Try to start named.service 3. Actual results: named timeouts and exits Expected results: named runs Additional info:
Fixed in bind-9.9.2-11.P1.fc19
Reopening, the /run/named vanishes after reboot as it is missing in named.conf in tmpfiles.d: # cat /etc/tmpfiles.d/named.conf d /var/run/named 0755 named named -
To fix this, I just had to add following line to /etc/tmpfiles.d/named.conf : d /run/named 0755 named named - Adam, what's the status of this bug? We need bind functional for users in our Test Day (Apr 18th).
dnsperf-2.0.0.0-5.fc19,bind-dyndb-ldap-3.1-2.fc19,bind-9.9.3-0.2.rc1.fc19,dhcp-4.2.5-10.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dnsperf-2.0.0.0-5.fc19,bind-dyndb-ldap-3.1-2.fc19,bind-9.9.3-0.2.rc1.fc19,dhcp-4.2.5-10.fc19
bind-9.9.3-0.2.rc1.fc19 should be fixed.
Package dnsperf-2.0.0.0-5.fc19, bind-dyndb-ldap-3.1-2.fc19, bind-9.9.3-0.2.rc1.fc19, dhcp-4.2.5-10.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnsperf-2.0.0.0-5.fc19 bind-dyndb-ldap-3.1-2.fc19 bind-9.9.3-0.2.rc1.fc19 dhcp-4.2.5-10.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5856/dnsperf-2.0.0.0-5.fc19,bind-dyndb-ldap-3.1-2.fc19,bind-9.9.3-0.2.rc1.fc19,dhcp-4.2.5-10.fc19 then log in and leave karma (feedback).
dnsperf-2.0.0.0-5.fc19, bind-dyndb-ldap-3.1-2.fc19, bind-9.9.3-0.2.rc1.fc19, dhcp-4.2.5-10.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.