Bug 460122

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

Thoughts Thomas?

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

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.

Paul

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