Bug 1298263
| Summary: | spamassassin starts before DNS is configured properly when using sysinit networking | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Matthew Miller <mattdm> |
| Component: | spamassassin | Assignee: | Ondřej Lysoněk <olysonek> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | qe-baseos-daemons |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | amahdal, mattdm |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-18 15:47:46 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: | |||
spamassassin starts
After=syslog.target network.target
When you disable NetworkManager, systemd might not tell you when the network is really ready. Common ever-green and fun of parallel boots.
Question is if these errors should not be fatal. It would "postpone" the real start of the service until the DNS is really ready and answering, if it is required to operate. Though it might break other setups.
This same topic is also discussed on Perlmonks [1] without any reasonable solution, but I would consider it as an misconfiguration:
> Discard NM *and* use a static resolv.conf which does not change between reboots.
Shouldn't you take care of your resolv.conf when using static configuration? But it leaves you writing the DNS servers in both ifcfg and resolv.conf, which is unfortunate.
Re-reading resolv.conf would be nice, but there is still two layers of abstraction between spamassassin and the file itself, Perl library and glibc. Having support for this in perl::Net::DNS would be at least convenient.
Debian report [2] of the similar topic is without any response so far. I will try to keep an eye on this bug, even though I am not sure if there is something we can do for it.
[1] http://www.perlmonks.org/?node_id=1130289
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741521
Static IPs and DNS can be set in NetworkManager. You can even have manual configuration and NetworkManager set to ignore configuration of specific interface. Individual services shouldn't do workarounds. Workarounds, if needed, should be done by systemd. Unfortunately I was not able to reproduce the problem on RHEL-7.2 nor on RHEL-7.5. What I did was (on a fresh installation) disable NetworkManager, enable spamassassin.service and configure /etc/sysconfig/network-scripts/ifcfg-eth0 as follows: DEVICE="eth0" BOOTPROTO="none" BOOTPROTOv6="none" ONBOOT="yes" TYPE="Ethernet" USERCTL="yes" PEERDNS="yes" IPV6INIT="no" PREFIX=24 IPADDR=192.168.122.2 DNS1=192.168.122.1 GATEWAY=192.168.122.1 I rebooted a couple of times, but spamassassin started up correctly, without errors, every time. I also tried adding 'sleep 5' to the top of /etc/sysconfig/network-scripts/ifup-eth, but appears the spamassassin service waits for the script to complete. Am I doing something wrong? Do I need to make any configuration changes to spamassassin? Closing. Feel free to reopen with additional info requested in comment#5. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |
Description of problem: The symptom: log messages like Jan 12 17:06:35 hostname spamd[18817]: dns: bad dns reply: Connection refused Jan 12 17:06:36 hostname spamd[27101]: dns: sendto() to [127.0.0.1]:53 failed: Connection refused, no more alternatives and DNS-based rules not working. The setup: * No local resolver * Static configuration with ifcfg entries containing ip addr and DNS servers * No NetworkManager Version-Release number of selected component (if applicable): spamassassin-3.4.0-2.el7.x86_64 How reproducible: repeatable. Steps to Reproduce: 1. Disable network manager; use static config 2. Reboot. Actual results: DNS errors about no server on localhost Expected results: Servers found in /etc/resolv.conf used. Additional info: It turns out that there is an empty (except for comments) /etc/resolv.conf.save. This appears to be swapped back in on system shutdown (at least, I think so, but network-functions is some seriously human-unreadable bash scripting). Then, spamassassin apparently starts _before_ the correct servers are written and, there we go. I guess it'd be most ideal if spamassassin realized that resolv.conf changed and updated to use the new servers. But failing that, maybe it could be started only after the interface is up?