Bug#929798: exim4-base: /etc/cron.daily/exim4-base will not rotate paniclog if it is 100% noise.

[Kyrian]

Quoting Andreas Metzler <ametzler at bebt.de>:

> On 2019-05-31 Kev Green <kyrian at 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.