Description of problem: I'm trying to run knot-resolver out of EPEL on CentOS 7.4.1708. Systemd opens a socket for it, but the daemon never starts, leaving these error messages in syslog: kresd: [system] bind to '127.0.0.1@53' Permission denied kresd: [system] bind to '::1@53' Permission denied Which is weird, because the systemd unit files shipped in the package set up socket activation, which (according to the documentation at https://knot-resolver.readthedocs.io/en/stable/daemon.html#running-supervised ) should work automatically. Looking at the source code, the socket activation code is within "#ifdef HAS_SYSTEMD" guards. Looking at the Makefile, this #define is set if libsystemd of version 227 or above is detected. This test was added in commit 50eebc07, in august of 2016 (first released in knot-resolver-1.1.0), with the comment that the sd_listen_fds_with_names() function call requires this version. CentOS 7 has version 219: $ rpm -qf /usr/lib64/libsystemd.so systemd-devel-219-42.el7_4.4.x86_64 Sure enough, when I fetch the SRPM and rebuild it, the Makefile does not detect systemd: [no] systemd (daemon) Version-Release number of selected component (if applicable): knot-resolver-1.5.0-1.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. yum -y install bind-utils knot-resolver-1.5.0-1.el7.x86_64 2. systemctl start kresd.socket 3. dig @localhost a a.root-servers.net Actual results: kresd doesn't start. dig fails: ;; connection timed out; no servers could be reached /var/log/messages contains: kresd: [system] bind to '127.0.0.1@53' Permission denied kresd: [system] bind to '::1@53' Permission denied [...] systemd: start request repeated too quickly for kresd.service systemd: Failed to start Knot DNS Resolver daemon. systemd: Unit kresd.socket entered failed state. systemd: kresd.service failed. Expected results: kresd should start and answer the query. Additional info: I assume an updated systemd isn't possible for CentOS, so can we get a unit file that starts kresd as a normal daemon instead of using socket activation?
I have read bug #1366968 and am running with SELinux disabled.
knot-resolver-1.5.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df
knot-resolver-1.5.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-24ac4ff7df
I tried knot-resolver-1.5.3-1.el7 on CentOS 7.4.1708. The provided socket activation-based unit file still doesn't work, but the one running as a regular daemon does.
Unfortunately, socket activation isn't going to work on CentOS 7, since the upstream uses certain functions that are only available in newer systemd.
Yes, I know. My point is that shipping a configuration that is never going to work alongside a working one is a bit confusing for the user.
I agree. I'll remove the unnecessary socket unit files in the future releases.
knot-resolver-2.1.0-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3
knot-resolver-2.1.0-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cee77fc9b3
knot-resolver-2.1.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.