Bug 6800

I've noticed that when mail originates from a local user to a local
user, the 'from' line is included in the log.  Mail originating from
a non-local user to a local user will not have the 'from' line in the
log.  Both of these test cases were performed after the logrotate.

I also tried installing the sendmail RPM from RedHat v6.0, and that
version DOES NOT seem to exhibit the same problem.

We have experienced an interaction issue with Logrotate, and sendmail.

This is properly a logrotate issue --- it is causing the fault to appear, by not
properly ensuring that sendmail is restarted ...

1. What occurs in a high sendmail load environment, such as the ISP at which the
issue was identified, is that sendmail is running a primary daemon  process,
listening for uncoming connections.  [This is the process number in the PID
file].

2. Additionally it has child processes handling mail, such as over a dialup
link.  These can take quite some time to complete a transfer.

3.  Logrotate fires off, and swaps out logfiles, optionally compresses, and the
like, and then runs a post-rotate script, which functionally does a:
    /etc/rc.d/inint.d/sendmail restart

4.  It (logrotate) will stop down the parent sendmail just fine.  It does NOT
however, affect the running children processes.  When the restart command tries
the 'start' side of the process, it fails, because it cannot bind to port 25.

5.  The present logrotate logic does not have an error-retry mechanism built
into it, and exits, _assuming_ that is has succeeded.

------------------------------

The result is that the host is left without a running sendmail daemon running,
and mail stacks up at a backup MX handler, unitl some-one notices, and manually
restarts sendmail.  Additionally the logging on the then running child processes
continues to the pre-rotation logfile; other errors (data loss) result if the
compression step is selected.

------------------------------

A fix is to modify the initscripts to instead "HUP" the daemon sendmail; rather
than the present 'restart' approach.

Additionally, a 'cronned monitoring' process, watching for the presence of a
daemon sendmail is a good idea, to 'automatically restart' a sendmail daemon if
it disappears.

This may be overkill on a single user host, but really pretty much necessary on
a production host.

assign to laroche

I was 'bitten' again by this in the last few days -- a long running atd process
fired off in /etc/cron.monthly was running and had an open sendmail fork --
another logrotate process aged out the sendmail logs, and 'restarted' sendmail,
without verifying that it had TRULY restarted sendmail .. and so I was left
without a sendmail running, due to Logrotate ...

I too have been bitten by this bug, but I do not agree that it is the fault or 
failure of logrotate.

Clearly, issuing /etc/init.d/sendmail restart will fail under the above 
conditions whether called from logrotate, from the command line or from a 
custom script.

It has failed for me under all three situations.

It is my belief that the init script should do the checking, and insure that 
the daemon has stopped before issuing a start, or should utilize the HUP as 
described above.  Then all three situations are resolved.

FYI ... the sendmail 8.11.6 is able to restart when JUSt the parent process is
killed, even of childred hang around.

It may be appropiate to close with a request for a re-open if the issue recurs.

Bug 6800 has been closed because it seems to be a mixture of 'how it is supposed
to work' for the child processes, and current fixes in sendmail for the parent
process.