Red Hat Bugzilla – Bug 460122
Sendmail doesn't send after reboot
Last modified: 2008-12-02 12:31:22 EST
Description of problem:
After every restart of my Fedora 9 system, sendmail starts, but it is unable to send messages out. This problem can be corrected by restarting sendmail with "service restart sendmail".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set the last line of /etc/aliases to route the SuperUser's mail to a remote mailbox.
2. Run newaliases.
3. Set SMART_HOST to appropriate hostname in /etc/mail/sendmail.mc.
4. Run make -C /etc/mail (with sendmail-cf installed).
5. Restart the system.
6. Try to send a message to an outside mailbox using the mail command (of the mailx package) or wait for Logwatch to run.
Mail never arrives at the desired mailbox. Lines like the following appear in /var/log/maillog:
Aug 26 04:49:30 ruuttest sendmail: m7Q1nR8x002463: from=root, size=2873, class=0, nrcpts=1, msgid=<200808260149.m7Q1nR8x002463@ruuttest.ml.ee>, re
Aug 26 04:49:30 ruuttest sendmail: m7Q1nUhI002749: from=<email@example.com>, size=3125, class=0, nrcpts=1, msgid=<200808260149.m7Q1nR8x002463@ru
uttest.ml.ee>, proto=ESMTP, daemon=MTA, relay=ruuttest.ml.ee [127.0.0.1]
Aug 26 04:49:30 ruuttest sendmail: m7Q1nR8x002463: to=root, ctladdr=root (0/0), delay=00:00:03, xdelay=00:00:00, mailer=relay, pri=32873, relay=[1
188.8.131.52] [127.0.0.1], dsn=2.0.0, stat=Sent (m7Q1nUhI002749 Message accepted for delivery)
Aug 26 09:32:37 ruuttest sendmail: m7Q1nUhI002749: m7Q6WbhJ002961: sender notify: Warning: could not send message for past 4 hours
Aug 26 09:32:37 ruuttest sendmail: m7Q6WbhJ002961: to=Frederick.New@MicroLink.ee, delay=00:00:00, mailer=relay, pri=34355, dsn=4.4.3, stat=queued
If I restart sendmail, the messages get delivered.
Sendmail should work correctly when the system is restarted.
Putting SELinux into permissive mode doesn't help and setroubleshoot doesn't show any problems.
Putting a correct entry in /etc/hosts for the SMART_HOST doesn't help.
I think my installation is pretty close to what you get from a default Fedora 9 installation except for the changes to /etc/aliases and /etc/mail/sendmail.mc (/.cf) as noted above. Well okay, I have also customized iptables a little. I can attach them, if desired.
The system has a static IP address assigned by DHCP and I am using NetworkManager (NetworkManager-0.7.0-0.9.4.svn3675.fc9.i386.rpm).
This is not a sendmail problem.
You could try to activate the network service and to deactivate NetworkManager.
Reassigining to NetworkManager.
will attempt to reproduce...
thomas: does sendmail handle address/interface changes? if sendmail is started before NM in the initscript ordering, perhaps it's not picking up the address after NM has assigned it?
fred: can you try adding NETWORKWAIT=10 to /etc/sysconfig/network and see if that helps? That will make startup block on NetworkManager setting up the interface completely before continuing.
Yes, with NETWORKWAIT=10 sendmail sends mail after a reboot without having to be restarted.
Ok, back to sendmail then since sendmail apparently cannot handle interface changes after it's been started. We have a few options here:
1) give sendmail a clue; avahi is a good reference here, as it will listen to netlink for interface events and reconfigure itself internally when interfaces appear, disappear, and when IP addresses are added and removed from those interfaces. This is the most "correct" option, but given that sendmail is not linux-specific it's likely upstream would take a while to accept such a patch. That doesn't mean it shouldn't be done in parallel with (2), (3), or (4)
2) Tell people who need sendmail like this to use NETWORKWAIT
3) Modify the sendmail startup script to block until a network is available or until a timeout has been reached like the NM startup script does
4) Create an NM dispatcher script to 'service sendmail restart' every time a network interface comes up or goes down
Dan: For 1): It is very unlikely that sendmail will accept a patch related to NM. 2) is only a part-solution, 3) is not practicable in server environments. Therefore 4) seems to be the best solution for now.
The NM dispatcher script should do a "service sendmail reload".
(In reply to comment #5)
> Dan: For 1): It is very unlikely that sendmail will accept a patch related to
Oh, this certainly isn't NM-related; it's a general linux problem. If you change the IP address on the interface, or you enable the interface after sendmail has started, you'll probably run into the problem even when NM isn't installed. It's a general problem that many old-school services (like NTP!) don't expect _any_ configuration to change after they are running. Unfortunately, that's no longer the case on many systems.
> 2) is only a part-solution
> 3) is not practicable in server environments.
Not true; if 'nm-online' doesn't exist (or if it does and NM is not running) then the startup script would simply continue without blocking. Only when NM is started does the script need to check if it needs to block, because NM may not have completed IP configuration of the interface by the time sendmail starts up if things are starting in parallel.
> Therefore 4) seems to be the best solution for now.
> The NM dispatcher script should do a "service sendmail reload".
Well, NM executes scripts in a certain directory when interfaces go up and down; there isn't one NM dispatcher script. For example, initscripts installs 05-netfs which will kick netfs when things change. I'd recommend doing something similar in the sendmail package. The script won't be executed when NM is (a) not installed or (b) not running, so there's no problem for people who don't use NM.
I have identified this bug as the cause for logwatch email not being received by root on a new F9 install. The logwatch people should probably be alerted to this as that was the first place that I looked for a solution to this.
This is also present in F10.
I've tried a little script that does option 4 in comment 4 and it seems to work (sendmail is restarted).
Given how quick and easy this is and the implications for system security and stability (e.g. notification from MD disk monitoring and denyhosts), I'm surprised this hasn't already been added.
*** This bug has been marked as a duplicate of bug 451575 ***