https://bugs.exim.org/show_bug.cgi?id=1891
Bug ID: 1891
Summary: exim waiting for input keeps log file open for ever
Product: Exim
Version: 4.87
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Logging
Assignee: nigel@???
Reporter: arekm@???
CC: exim-dev@???
Summary: exim waiting for input keeps log file open for ever
Real live scenario:
|-crond(3647)-+-run-parts(3650)---cmd.py(5905,nobody)
| `-sendmail(3710,exim)
crond starts a process that never ends. cmd.py can be working for months or
years (it is supposed to do so).
cmd.py outputs some data to stdout and crond starts sendmail process to deliver
that output via mail.
The problem is that exim when invoked as sendmail keeps log file open. log file
which is later rotated and deleted but sendmail keeps it open:
sendmail 3710 exim 4w REG 254,0 5572399
33635911 /var/log/archive/exim/main.log-20160906 (deleted)
main.log is logrotated via logrotate:
/var/log/exim/main.log {
olddir /var/log/archive/exim
create 640 exim exim
daily
delaycompress
}
Sending HUP doesn't help:
# lsof 2>&1 | grep 3710 |grep delete
sendmail 3710 exim 4w REG 254,0 5572399
33635911 /var/log/archive/exim/main.log-20160906 (deleted)
# kill -HUP 3710
# lsof 2>&1 | grep 3710 |grep delete
sendmail 3710 exim 4w REG 254,0 5572399
33635911 /var/log/archive/exim/main.log-20160906 (deleted)
Maybe exim should reopen log if it is rotated?
Like solution seen in WatchedFileHandler in python logging. It simply checks
few things:
if not sres or sres[ST_DEV] != self.dev or sres[ST_INO] != self.ino:
... reopen
Not sure how to approach this (of course I could try to change cmd.py to don't
output anything to stdout/stderr but what cmd.py does currently is perfectly
valid/allowed scenario)
--- Comment #1 from Jeremy Harris <jgh146exb@???> ---
*** Bug 1892 has been marked as a duplicate of this bug. ***
--- Comment #2 from Jeremy Harris <jgh146exb@???> ---
Currently the logfile is checked for having been cycled any time we're
about to write to it. I guess it might be possible to deliberately close
an open log every so often (on order of daily, perhaps).
Working that in without abusing an alarm signal-handler may be troublesome
though. I assume we're blocked reading stdin... perhaps a poll/select on
that; then after an hour would not be unfair.
--- Comment #3 from Jeremy Harris <jgh146exb@???> ---
*** Bug 1893 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.