This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 451575 - sendmail doesn't resolve names when running NetworkManager
sendmail doesn't resolve names when running NetworkManager
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
rawhide
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
: 460122 477548 479107 (view as bug list)
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2008-06-15 19:56 EDT by Horst H. von Brand
Modified: 2013-01-09 23:43 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-03 13:37:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Horst H. von Brand 2008-06-15 19:56:15 EDT
Description of problem:
I'm using fetchmail to download my mail. When using my WiFi network at home, I
have to restart sendmail to get my mail. I guess this is due to glibc's resolver
code not finding out that /etc/resolv.conf has changed, or some such.

Version-Release number of selected component (if applicable):
sendmail-8.14.2-4.fc9.i386
glibc-2.8.90-7.i686

How reproducible:
Always

Steps to Reproduce:
1. Start machine on WiFi, log in
2. Start fetchmail; no mail downloaded (" reject=451 4.1.8 Domain of sender does
not resolve" in /var/log/maillog)
3.
  
Actual results:


Expected results:


Additional info:
Restarting sendmail cures this
Comment 1 Thomas Woerner 2008-06-17 05:34:57 EDT
With the old network scripts sendmail is working if you are connected over a ppp
line where resolv.conf gets changed. Therefore this is not a sendmail problem.

Assigning to NetworkManager.
Comment 2 Horst H. von Brand 2008-06-19 19:11:48 EDT
It turned out that nscd hadn't started (or had crashed?). Restarting that one
fixed things. Should this be thrown at the glibc maintainer?
Comment 3 Horst H. von Brand 2008-06-19 22:00:06 EDT
Sorry, wrong alarm. A few mails seemed to make it through, but I had to restart
sendmail anyway.
Comment 4 Horst H. von Brand 2008-07-28 12:58:21 EDT
Now on x86_64, same thing

sendmail-8.14.3-1.fc10.x86_64
glibc-2.8.90-9.x86_64
glibc-2.8.90-9.i686
NetworkManager-0.7.0-0.11.svn3846.fc10.x86_64
Comment 5 Dan Williams 2008-10-17 12:06:32 EDT
is this still an issue with latest rawhide NetworkManager?
Comment 6 Horst H. von Brand 2008-10-19 12:10:15 EDT
Yep, checked yesterday (rawhide up to date).
Comment 7 Dan Williams 2008-10-27 14:18:46 EDT
Horst, is nscd enabled on your machine?  What do you get for '/sbin/chkconfig --list | grep nscd'?  And if it is running when DNS changes, does doing '/usr/sbin/nscd -i hosts' as root work for you?
Comment 8 Orion Poplawski 2008-10-28 11:06:06 EDT
I'm also thinking that NM should do a "nscd -i hosts" when DNS changes (or perhaps nscd should monitor /etc/resolv.conf and automatically flush when it changes?).  Problem I'm seeing here is laptops moving from home to/from work and accessing the wrong (public vs. private) IP address for services.  Thunderbird seems particularly affected.
Comment 9 Horst H. von Brand 2008-10-28 19:12:17 EDT
NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64, freshly booted. Still the same problem.

# /sbin/chkconfig --list | grep nscd
nscd           	0:off	1:off	2:off	3:off	4:off	5:off	6:off
Comment 10 Jesse Keating 2008-10-28 19:18:34 EDT
Moving off of preview target, not a preview blocker.

Horst, nscd needs to run if you want things to notice network config changes.  Try booting with the service enabled and see if it resolves your issue.
Comment 11 Dan Williams 2008-10-28 23:52:17 EDT
(In reply to comment #8)
> I'm also thinking that NM should do a "nscd -i hosts" when DNS changes (or
> perhaps nscd should monitor /etc/resolv.conf and automatically flush when it
> changes?).  Problem I'm seeing here is laptops moving from home to/from work
> and accessing the wrong (public vs. private) IP address for services. 
> Thunderbird seems particularly affected.

NM does both 'nscd -i hosts' and a condrestart of nscd when DNS information changes.
Comment 12 Orion Poplawski 2008-10-29 11:58:19 EDT
I think the problem is that sendmail uses res_querydomain() to resolve names and does not check to see if /etc/resolv.conf has changed.  sendmail is started before a working /etc/resolv.conf is in place and seems to be stuck with that information.  So, either:

1) sendmail should monitor resolv.conf and call res_init() if needed, or simply call res_init() before querying names (this is what fetchmail does).

2) NM should condrestart sendmail.

3) sendmail should use something other than res_querydomain() (is that possible since it looks for AAAA, A, then MX records?)

I'm thinking #1,  though I may have to do #2 with a dispatch script as a workaround.

Here's an strace snippet of the sendmail daemon processing an incoming mail:

2442  write(1, "dns_getcanonname: trying test.cor"..., 52) = 52
2442  socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
2442  connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("0.0.0.0")}, 28) = 0

Note how it tries to connect to a dns server at 0.0.0.0.

See also: http://sources.redhat.com/bugzilla/show_bug.cgi?id=3675 for the glibc perspective.
Comment 13 Jesse Keating 2008-10-29 13:34:24 EDT
This feels like something we'll want to fix post-F10, as it would be a somewhat interesting change to sendmail.  I'm dropping it off the list.  I think for sendmail users, they can just set the setting in /etc/sysconfig/network to wait for NM to fully bring up the device before continuing on with startup scripts.
Comment 14 Dan Williams 2008-10-29 23:55:46 EDT
Given comment 12, it's more of a sendmail package problem.  NM can't contain scripts to restart every service under the sun, thus the sendmail package would have to have one.  Or it grows the ability to requery /etc/resolv.conf...  -> sendmail
Comment 15 Horst H. von Brand 2008-10-31 22:01:35 EDT
(In reply to comment #13)
> This feels like something we'll want to fix post-F10, as it would be a somewhat
> interesting change to sendmail.  I'm dropping it off the list.  I think for
> sendmail users, they can just set the setting in /etc/sysconfig/network to wait
> for NM to fully bring up the device before continuing on with startup scripts.

This doesn't help if you have sendmail running so you can send off (really queue) mail even when there is no network.
Comment 16 Orion Poplawski 2008-10-31 22:28:25 EDT
(In reply to comment #15)
> This doesn't help if you have sendmail running so you can send off (really
> queue) mail even when there is no network.

I have to say, I'm getting much more reliable delivery of system messages from our laptops now that I'm restarting sendmail in my NM dispatcher script and the queue is processed as soon as the network is up.  But again, the proper fix is in sendmail calling res_init().
Comment 17 Bug Zapper 2008-11-25 21:25:57 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Jon Stanley 2008-11-26 14:13:29 EST
Fixing version to align with rawhide again.  Sorry for the noise.
Comment 19 Miroslav Lichvar 2008-12-02 12:31:22 EST
*** Bug 460122 has been marked as a duplicate of this bug. ***
Comment 20 Miroslav Lichvar 2008-12-03 13:37:03 EST
A NM dispatcher script added in sendmail-8.14.3-2.fc11.
Comment 21 Fedora Update System 2008-12-03 13:54:56 EST
sendmail-8.14.3-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/sendmail-8.14.3-2.fc10
Comment 22 Fedora Update System 2008-12-19 08:40:01 EST
sendmail-8.14.3-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/sendmail-8.14.3-3.fc10
Comment 23 Miroslav Lichvar 2008-12-22 05:32:29 EST
*** Bug 477548 has been marked as a duplicate of this bug. ***
Comment 24 Horst H. von Brand 2008-12-22 10:00:37 EST
It seems #20 fixed this for me (rawhide x86_64). Should it be closed? Backport fix to Fedora 9 and 10?
Comment 25 Andreas M. Kirchwitz 2008-12-22 11:56:41 EST
Hi folks, I come from ticket #477548 (same problem). Is it possible
that somebody corrects the typo in the summary, so that other people
have a chance to find this ticket when they search for "sendmail"
(and not "sedndmail" ;-)
Comment 26 Horst H. von Brand 2008-12-22 12:56:36 EST
Fixed.

Sorry, my typo.
Comment 27 Miroslav Lichvar 2009-01-07 05:48:40 EST
*** Bug 479107 has been marked as a duplicate of this bug. ***
Comment 28 Fedora Update System 2009-01-07 16:53:27 EST
sendmail-8.14.3-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 29 vaistout 2009-07-13 13:41:12 EDT
we had the problem on Fedora 11:
- 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
- NetworkManager-0.7.1-4.git20090414.fc11.x86_64
- sendmail-8.14.3-5.fc11.x86_64

system logfiles said this almost all the time:
reject=451 4.1.8 Domain of sender address example@example.com does not resolve

- we solved this issue by disabling NetworkManager init process ( chkconfig  NetworkManager off ) and using the standard network config files ( /etc/sysconfig/network-scripts/ifcfg* )

if this is already known, sorry for reporting, we wont do again :)

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