|Summary:||sendmail logs stop working after they're rotated|
|Product:||[Retired] Red Hat Linux||Reporter:||bwelling|
|Component:||sendmail||Assignee:||Florian La Roche <laroche>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||6.1||CC:||herrold, lyonsa, pholcomb|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-01-24 18:59:45 UTC||Type:||---|
|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 normal.
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 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.
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.