Red Hat Bugzilla – Bug 477548
sendmail fails if NetworkManager does not wait
Last modified: 2008-12-22 05:32:29 EST
Description of problem:
During boot process, sendmail usually comes up before NetworkManager
has established the network connectivity. Sendmail seems to require
network connectivity because it's impossible to send out any mail to
another machine. Mail is stuck in the mail queue (see "mailq"), and
/var/log/maillog is full of messages like this:
Dec 21 04:57:57 myhost sendmail: mBJ7haMc019935: email@example.com, delay=1+20:14:21, xdelay=00:00:00, mailer=esmtp, pri=3366951, relay=external.example.com., dsn=4.0.0, stat=Deferred: Name server: external.example.com.: host name lookup failure
If I run "sendmail -q" or "/etc/init.d/sendmail restart", sendmail is
finally able to send out mail. However, that only helps until next
reboot of the machine.
To fix the problem permanently, I've added "NETWORKWAIT=yes" to
/etc/sysconfig/network (as suggested by various documentation).
Documentation also recommends to file a bug report if any
applications are found that don't work with NetworkManager;
so that's what I'm doing right now.
By the way, Squid has the same problem. Upon startup Squid checks
all name servers and never tries again. Same workaround as for Sendmail.
Version-Release number of selected component (if applicable):
Always after boot.
Steps to Reproduce:
1. Install Fedora 10 and try to send mail to an external machine on the net.
2. Use "date | mail -s test firstname.lastname@example.org" or put the address in "~root/.forward" and wait for the daily logwatch mail.
3. See /var/log/maillog and output of "mailq".
Mail to external machines is stuck in the mail queue forever.
Mail should be sent out properly.
Adding "NETWORKWAIT=yes" to /etc/sysconfig/network fixes the problem.
Fedora 9 has the same bug (you found it lot of occurences on the web for
this issue, but I couldn't find a bugzilla ticket on that topic).
IMHO, "NETWORKWAIT=yes" should be set by default as Sendmail is not the
only application that requires network connectivity on startup. Debugging
that issue has cost me a lot more time than the few saved seconds during
*** This bug has been marked as a duplicate of bug 451575 ***