Quoting Andreas Metzler <ametz...@bebt.de>:
On 2019-05-31 Kev Green <kyr...@ore.org> wrote:
Package: exim4-base
Version: 4.84.2-2+deb*
Severity: normal
[...]
* What exactly did you do (or not do) that was effective (or
ineffective)?
Doing $E4BCD_PANICLOG_NOISE to begin with was one mitigation, but it
does not respect the 'once' mode of $E4BCD_WATCH_PANICLOG so warning
emails keep coming until manual intervention is done.
I do not get this part of the bug-report. Afaict from looking at the
script the following happens (in pseudocode):
1. Check for nonempty paniclog.
2. If E4BCD_PANICLOG_NOISE is not set or if paniclog contains lines NOT
ignored by E4BCD_PANICLOG_NOISE then
a) send out a warning mail
b) rotate log if "$E4BCD_WATCH_PANICLOG"="once"
So if paniclog is non-empty, but only contains ignored lines then the
log is not-rotated but warning mails are not sent out. So "warning
emails keep coming" will not happen.
cu Andreas
Yes, I agree that is the logic that the script follows.
Anyway, having worked through it all again in my head and worked out
the bits that are deliberate on the developer's part, and the red
herrings, I think this is the issue I meant...
If you have a paniclog full of rubbish you want to ignore (say
4138/4143 lines are junk in the log, and the error is not in the last
$E4BCD_PANICLOG_LINES lines), the step that does 'tail -n' on the
paniclog and sends it out without filtering in the same way with
$E4BCD_PANICLOG_NOISE, then all the email gives you are the lines of
noise (which looks remarkably similar day-to-day if it's all exactly
the same error with just different timestamps, and perhaps that lead
me to think 'once' was being ignored), not the actual non-ignored
lines that triggered the email.
I think that's what got me thinking that the log rotation should
happen if the paniclog has *something* in it even if it's junk that
you ignore, because you can get a loooot of junk in those logs. That
might end up being counter-intuitive for some use cases though I
guess. Another thing to do might be to change the "tail -n" line to:
grep -v "$E4BCD_PANICLOG_NOISE" /var/log/exim4/paniclog | tail -n
"${E4BCD_PANICLOG_LINES}"
It struck me as a bug initially because I thought when grep finds no
matches it returns 1 rather than 0 might be tripping up the script
logic, but what you say above suggests that was intentional.
As best I can tell, the "tail -n" line is unchanged up to the most
recent package version.
This is sounding more like a feature request than a bug I suppose.
K.
