https://bugs.exim.org/show_bug.cgi?id=728
Heiko Schlittermann <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #10 from Heiko Schlittermann <[email protected]> ---
(In reply to Andreas Pflug from comment #3)
> Hypothesis: logwrites are being done infrequently by this process, only for
> exceptional conditions (as you don't log new connections), one such does not
> close the log after, and this is only detected on the next logwrite attempt.
>
> I'm not seeing it in production as I do log new connections, so it happens
> but
> only briefly. Would adding "pid" to your log_selector be feasible, with your
> log volume? We might then nail down the messages coming from the daemon
> process.
> I guess the issue will be any post-processing you do on logs.
After a short glance into log.c, Exim doesn't close the (main)log after
writing. But before a write attempt, Exim checks if the file is still
the one that was opened (comparison mainlog_inode with the current inum
of the file named 'mainlog').
If it's a new file, exim re-opens it.
Thus, Jeremy's theory is almost right. The logrotation gets detected
only on a write attempt. If the master process doesn't use log_write, it
stays opened forever.
It's done that way for efficieny, I think.
It this critical? It might. Because if you rotate/remove your logs for
disk capacity reasons, you won't free anything.
BTW: running an 4.84 I do not see the opened mainlog. Did this change?
How to solve it?
- HUP the master process after logrotation, this will force
a logwrite and trigger the re-open
- Let exim check on a more ore less regularly basis if the
mainlog needs to be re-opened. (E.g. On every client connection,
even without logging. But this leaves room for improvementâ¦)
- Keep the log open only for a limited time and then close it.
(This is IMHO the best solution, but this needs to be some scheduled
job inside Exim. Do we have a framework for such jobs already? I
don't think soâ¦)
Best regards from Dresden/Germany
Viele GrüÃe aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
--
You are receiving this mail because:
You are on the CC list for the bug.--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
