Bug 6800

Summary: sendmail logs stop working after they're rotated
Product: [Retired] Red Hat Linux Reporter: bwelling
Component: sendmailAssignee: Florian La Roche <laroche>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: herrold, lyonsa, pholcomb
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-24 18:59:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description bwelling 1999-11-07 19:22:53 UTC
Normally, for each incoming message, /var/log/maillog logs 2
lines, a 'from' line and a 'to' line.  After the log is
rotated, though, the 'from' line is no longer logged, only
the 'to' line.  Restarting sendmail returns everything to

Comment 1 dhinkle 1999-11-11 15:49:59 UTC
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.

Comment 2 R P Herrold 2000-02-28 15:27:59 UTC
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

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.

Comment 3 Cristian Gafton 2000-05-22 15:51:59 UTC
assign to laroche

Comment 4 R P Herrold 2001-03-25 19:44:20 UTC
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 ...

Comment 5 Timothy Burt 2001-08-31 12:46:46 UTC
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.

Comment 6 R P Herrold 2001-09-28 03:32:05 UTC
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.

Comment 7 Stephen John Smoogen 2003-01-24 18:59:45 UTC
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