Hi,

As per /usr/sbin/logcheck, when logcheck is run, the LOGFILES
variable is set as the following concatenation:
"("$LOGFILES_LIST" "$LOGFILES_LIST_D"/*.logfiles").

This defeats using an alternate logfiles file since the logfiles
in logfiles.list.d are unconditionally appended to the logfiles
list.

Hence, the -L option does not overrules anymore the default
logfiles list as stated in the manpage, it now extends it.

We are impacted here since in addition to logcheck standard
configuration we use a second set of applications specific log
files for specific logcheck examinations run with a different
cron periodicity than the standard one. This way log messages
reported by this second set of "application" reports do not
get mingled with the standard "system" reports, and vice-versa.

As you might have guessed, this implies the lines in
logcheck.logfiles.d/journal.logfiles are all commented out in
our configurations, we only use syslog.logfiles.

Would you mind modifying the logcheck script so that the -L
option keeps working as a complete alternative to
logcheck.logfiles, as it used to?

Thanks in advance,

Hi,

To be more precise, the problem showed up here when logcheck
configuration started to use the logcheck.logfiles.d files by default,
i.e. when we upgraded some hosts to bookworm. Before that, since there
was no files in this directory, concatenating its files contents to the
LOGFILES variable was essentially a no-op.

Yet the directory itself (and the related handling of it in the script)
seems to be at least as old as stretch.

Regards,

true - we should perhaps clarify the documentation to make this clearer


(it's nice to hear about people doing things like this - i have some
thoughts about new features so good to have some understanding of use-caes
so we dont break this kind of thing by mistske!)

As you might have guessed, this implies the lines in

i think there is a better solution already available

you can use the -D option to avoid the standard the logfiles.d directory -
set it to -L new.file -D /dev/null or to any empty directory. we do this
with /dev/null in the debian tests so i am confident it works, if it doesnt
that is a bug!

(i think we should say this in the documentation )


as you say in your other mail, this isnt a change in bookworm just more
obvious now we are using the .d directory.

thanks for the report!

Hi,

Le 27/07/2023 à 18:12, Richard Lewis a écrit :

Yes, it works, I just tested it! I should have thought about that, sorry.

Yes, this is the only kind of fix needed, actually.

Thanks to you for this tool I've been using since slink (or was it
hamm?)! Congrats to you guys, keep up the good work!