Bug 460122 - Sendmail doesn't send after reboot
Sendmail doesn't send after reboot
Status: CLOSED DUPLICATE of bug 451575
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
9
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-26 06:21 EDT by Fred New
Modified: 2008-12-02 12:31 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Fred New 2008-08-26 06:21:27 EDT
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):
sendmail-8.14.2-4.fc9.i386

How reproducible:
Always

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.
  
Actual results:

Mail never arrives at the desired mailbox.  Lines like the following appear in /var/log/maillog:

Aug 26 04:49:30 ruuttest sendmail[2463]: m7Q1nR8x002463: from=root, size=2873, class=0, nrcpts=1, msgid=<200808260149.m7Q1nR8x002463@ruuttest.ml.ee>, re
lay=root@localhost
Aug 26 04:49:30 ruuttest sendmail[2749]: m7Q1nUhI002749: from=<root@ruuttest.ml.ee>, 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[2463]: m7Q1nR8x002463: to=root, ctladdr=root (0/0), delay=00:00:03, xdelay=00:00:00, mailer=relay, pri=32873, relay=[1
27.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m7Q1nUhI002749 Message accepted for delivery)
Aug 26 09:32:37 ruuttest sendmail[2961]: m7Q1nUhI002749: m7Q6WbhJ002961: sender notify: Warning: could not send message for past 4 hours
Aug 26 09:32:37 ruuttest sendmail[2961]: 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.


Expected results:
Sendmail should work correctly when the system is restarted.


Additional info:
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).
Comment 1 Thomas Woerner 2008-08-26 07:29:55 EDT
This is not a sendmail problem.

You could try to activate the network service and to deactivate NetworkManager.

Reassigining to NetworkManager.
Comment 2 Dan Williams 2008-08-26 21:04:36 EDT
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.
Comment 3 Fred New 2008-08-27 04:02:57 EDT
Yes, with NETWORKWAIT=10 sendmail sends mail after a reboot without having to be restarted.
Comment 4 Dan Williams 2008-08-27 07:20:35 EDT
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

Thoughts Thomas?
Comment 5 Thomas Woerner 2008-08-27 11:22:23 EDT
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".
Comment 6 Dan Williams 2008-08-27 11:37:13 EDT
(In reply to comment #5)
> Dan: For 1): It is very unlikely that sendmail will accept a patch related to
> NM.

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

Definitely.

> 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.
Comment 7 John DeDourek 2008-11-13 10:56:23 EST
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.
Comment 8 Paul Black 2008-12-01 08:45:01 EST
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.

Paul
Comment 9 Miroslav Lichvar 2008-12-02 12:31:22 EST

*** This bug has been marked as a duplicate of bug 451575 ***

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