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