Bug 1409596 - Issue w/ Sendmail, NetworkManager and V6 DNS
Summary: Issue w/ Sendmail, NetworkManager and V6 DNS
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: sendmail
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-02 15:11 UTC by dan
Modified: 2017-12-12 10:18 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 10:18:13 UTC
Type: Bug


Attachments (Terms of Use)

Description dan 2017-01-02 15:11:57 UTC
Description of problem:

When sendmail first tries to start right after system boot it does not appear to make use of the IPv6 nameservers configured on my system.  Therefore any mail sent receives:

451 4.1.8 Domain of sender address dan@somehost.com does not resolve

A restart of sendmail cures the problem.

This occurs when resolv.conf contains only IPv6 nameservers.  If IPv4 nameservers are added prior to the v6 listings the problem does not occur.

I enabled the NetworkManager-wait-online.service but it did not help.

I then booted the host using only the v6 nameservers, had tcpdump running, and saw that on a connection to port 25, the recipient destination was not being queried on the v6 DNS listed in resolv.conf.  There was no DNS traffic.  I restarted sendmail and then the v6 queries worked properly.

The DNS servers, whether IPv4 or 6 are being provided by NetworkManager.

Comment 1 dan 2017-01-02 23:07:27 UTC
Confirmed that this is something between sendmail and NetworkManager.  Disabled NetworkManager.service and enabled the older network.service and the problem evaporates.

Comment 2 John Damm Sørensen 2017-03-20 10:35:17 UTC
I have a similar problem with only IPv4 name servers.

After a reboot mails are deferred:

From mailq: (host map: lookup (yahoo.com): deferred)

The log shows:
 --- 451 yahoo.com: Name server timeout
 --- 050 <XXXXXXXXXX@yahoo.com>... Transient parse error -- message queued for future delivery
 --- 451 yahoo.com: Name server timeout

I too tried the NetworkManager-wait-online.service and increased the time out to 300 seconds. But that didn't help either.

I also tried to increase the sendmail resolver retries:
O Timeout.resolver.retry.first=40000
Assuming that this would cause sendmail to keep retying for  5*40000 seconds.

I then disabled NetworkManager services and enabled the old network.service and now sendmail works without a restart after reboot.

So there is definitely a problem with the interaction between sendmail and NetworkManager. Only problem is what and how to debug it further.

Comment 3 John Damm Sørensen 2017-03-20 16:32:33 UTC
This problem is rather strange.

I thought that the most likely reason for this problem to appear would be that the file /var/run/NetworkManager/resolv.conf (pointed to by the symbolic link /etc/resolv.conf) is created after sendmail starts thus making the resolver fail. That would explain why increasing the resolver retries didn't help.

So I disabled network.service and enabled NetworkManager.service and rebooted.

Now sendmail works without a restart and examining the time stamps of /var/run/NetworkManager/resolv.conf and the start up time of sendmail shows that sendmail starts after the creation of /var/run/NetworkManager/resolv.conf.

Mar 20 17:09:47 www sm-msp-queue[2448]: starting daemon (8.15.2): queueing@01:00:00
Mar 20 17:09:49 www sendmail[2435]: NOQUEUE: stopping daemon, reason=signal
Mar 20 17:09:49 www sendmail[2532]: starting daemon (8.15.2): SMTP+queueing@01:00:00
Mar 20 17:09:49 www sendmail[2532]: STARTTLS: CRLFile missing
Mar 20 17:09:49 www sendmail[2532]: STARTTLS=server, Diffie-Hellman init, key=2048 bit (I)
Mar 20 17:09:49 www sendmail[2532]: STARTTLS=server, init=1
Mar 20 17:09:49 www sendmail[2532]: started as: /usr/sbin/sendmail -bd -q1h
Mar 20 17:09:49 www sm-msp-queue[2544]: starting daemon (8.15.2): queueing@01:00:00


# stat /var/run/NetworkManager/
   Fil: '/var/run/NetworkManager/'
  Stør: 60              Blokke: 0          IO-blokke: 4096   katalog
Enhed: 15t/21d  Inode: 24823       Lænker: 2
Adgang: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Adgang: 2017-03-20 17:09:39.355124166 +0100
Redig.: 2017-03-20 17:09:42.728226631 +0100
Ændret: 2017-03-20 17:09:42.728226631 +0100
Opret.: -


# stat /var/run/NetworkManager/resolv.conf
   Fil: '/var/run/NetworkManager/resolv.conf'
  Stør: 68              Blokke: 8          IO-blokke: 4096   almindelig fil
Enhed: 15t/21d  Inode: 30719       Lænker: 1
Adgang: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Adgang: 2017-03-20 17:13:55.974222842 +0100
Redig.: 2017-03-20 17:09:42.728226631 +0100
Ændret: 2017-03-20 17:09:42.728226631 +0100
Opret.: -

Comment 4 Fedora End Of Life 2017-11-16 19:22:20 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. 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 '25'.

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 25 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.

Comment 5 Fedora End Of Life 2017-12-12 10:18:13 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.


Note You need to log in before you can comment on or make changes to this bug.