Description of problem: If you're network is slow coming up (say you're using DHCP and the server is unavailable or rebooting after a power outage, etc) then this service might come up before the network is sufficiently configured. Recommend adding [Unit] Wants=network-online.target After=network-online.target to .service file. Version-Release number of selected component (if applicable): sendmail-8.15.2-19.fc26.x86_64 How reproducible: Bring up host while DHCP server is down. Steps to Reproduce: 1. Provision host to use DHCP 2. Shutdown DHCP server 3. Reboot host under test Actual results: Service starts with wrong host name, domain name, etc. and doesn't learn it after DHCP comes back (not without restarting the service, anyway). Expected results: Service should not be started until network is adequately configured. Additional info:
I treat DHCP usage in a server environment as questionable, given public SMTP servers are supposed to not often change their IP address e.g. due to reputation databases, DNSBLs etc. On the other hand, there also might be admins that hardcode the IP address (for binding) and/or hostname, etc. in sendmail.mc. Last of it is IMHO a better choice rather relying on whatever comes via DHCP.
(In reply to Robert Scheck from comment #1) > I treat DHCP usage in a server environment as questionable, given public > SMTP servers are supposed to not often change their IP address e.g. due to > reputation databases, DNSBLs etc. On the other hand, there also might be > admins that hardcode the IP address (for binding) and/or hostname, etc. in > sendmail.mc. Last of it is IMHO a better choice rather relying on whatever > comes via DHCP. You're assuming that the servers aren't NATted on RFC-1918 addresses. If something had a truly fixed (and routable) address, then using DHCP would make no sense. But if it's a masqueraded address, then DNSBL doesn't really enter into it. You wouldn't need to hardcode the hostname (into sendmail.cf) if you're setting it properly with the hostname(1) command.
(In reply to Philip Prindeville from comment #2) > You're assuming that the servers aren't NATted on RFC-1918 addresses. If > something had a truly fixed (and routable) address, then using DHCP would > make no sense. But if it's a masqueraded address, then DNSBL doesn't really > enter into it. Given the scenario that you are describing seems to be IPv4 specific, I wonder if it makes sense nowadays to perform IPv4-only specific optimizing. At IPv6, things are different and restarting sendmail depending on IPv4 specific conditions even leads to a disconnect of all IPv6 SMTP connections, which IMHO is a real-life disadvantage (especially at common dual-stacked server environments), while I would consider IPv4-only as legacy environment. > You wouldn't need to hardcode the hostname (into sendmail.cf) if you're > setting it properly with the hostname(1) command. But, if you are setting the hostname/domain properly via hostnamectl(1), there IMHO is even no need to wait for the DHCP client at all...
(In reply to Robert Scheck from comment #3) > Given the scenario that you are describing seems to be IPv4 specific, I > wonder if it makes sense nowadays to perform IPv4-only specific optimizing. There are a lot of ISP's (even business providers) which don't support IPv6 here in the US. I'm guessing that on your side of the ocean IPv4 seems pretty quaint, but over here it's still the workhorse of networking. > At IPv6, things are different and restarting sendmail depending on IPv4 > specific conditions even leads to a disconnect of all IPv6 SMTP connections, > which IMHO is a real-life disadvantage (especially at common dual-stacked > server environments), while I would consider IPv4-only as legacy environment. > > > You wouldn't need to hardcode the hostname (into sendmail.cf) if you're > > setting it properly with the hostname(1) command. > > But, if you are setting the hostname/domain properly via hostnamectl(1), > there > IMHO is even no need to wait for the DHCP client at all... What I was also implying was that DHCP would be calling sethostname() directly or via a shell script as I do, in /etc/dhcp/dhclient.d/hostname.sh ...
(In reply to Philip Prindeville from comment #4) > There are a lot of ISP's (even business providers) which don't support IPv6 > here in the US. I'm guessing that on your side of the ocean IPv4 seems > pretty quaint, but over here it's still the workhorse of networking. "ARIN's free pool of IPv4 address space was depleted on 24 September 2015." as their website states, so if US providers do only care about legacy IP, it still is IMHO not the way to go for Fedora, because it would disadvantage all future-oriented dual-stack users vs. some customers of US providers that prefer legacy IP-only (and DHCP for servers).
Sendmail can get to race condition with NetworkManager also on ipv4 on a server with many network cards with STATIC network configuration not using DHCP. I agree that the dependency should be on network-online.target and not only on the network.target.
Michal, may I kindly ask for a technical example for this situation? When just having multiple NICs with static network configuration, I was not yet able to reproduce such an issue.
Hello Robert, I have seen this practically happening with postfix (bug #1510158) not sendmail, but I believe the principle is the same. Let's say you have following race condition scenario: - you have multiple cards such as 1 for doing SMTP, one for backups/management, one spare for the case one of the cards gets broken etc. - you have decently fast machine/disks so the file operations are much faster comparing the networking timeouts - you do not bind sendmail to allmighty 0.0.0.0, but you have some explicit IP or name to bid to such as: DAEMON_OPTIONS(`Name=example.net, Addr=smtp.example.net') or DAEMON_OPTIONS(`Name=example.net, Addr=111.222.33.44) - During reboot NetworkManager is just started - it takes it some time to bring the network cards up and this is not finished. - At this particular race condition moment the sendmail is started by systemd - if configured with hostname it systemd-resolved will resolve the local hostname as 127.0.0.2. Or if there is some record in /etc/hosts it will get the right IP - in either case the bind to the IP address will fail at this moment, because the IP is not configured yet on the card - then network gets to online status - resolves of the localhostname will work fine now - manual restart of the sendmail service will be OK as well Best regards Michal
Part of the problem is also that the unit files such as /usr/lib/systemd/system/sendmail.service are usually not marked as configuration files so even if you change it manually from network.target to netork-online.target, it will revert back with another patching.
(In reply to Michal Ambroz from comment #9) > Part of the problem is also that the unit files such as > /usr/lib/systemd/system/sendmail.service are usually not marked as > configuration files so even if you change it manually from network.target to > netork-online.target, it will revert back with another patching. This is why systemd drop-in units exist, to make such changes update-safe, e.g. https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.