I have used logcheck on testing for many years.  Being on testing, I occasionally had to add local rules to keep it up.  Usually logcheck signaled few lines every day, sometimes no line, sometims (at reboot or big updates) many lines.

Starting maybe a couple years ago, logcheck spits an amount of stuff that has now become unamnageable.  While in the beginning logs were relevant to the system, which is what I want, now any bug in a user-level daemon writing info to the syslog or to the systemsctl thing makes havoc.  I had many email tens of megabytes long.  In the last month, reports have been completely useless to me as they are filled with useless things and I am busy adding local rules to remove them

Now I have reached a point where its usefulness is negative: I spend more time adding rules than it is worth for me getting the info.

One cure would be to have logcheck ignore user-level messages, and only care about system-level ones.  Is that possible?

control: reassign -1 logcheck-database
thanks
(this is mostly about logcheck-database)


logcheck-database was mostly dormant sround that time. im hoping to improve
that, but it is a big task and needs some wider improvements. So: please
bear with it!


While in the beginning logs were relevant to the system, which is what I


i sympathise


 however:
- a bug in a daemon should ideally be reported and fixed in the daemon
- this may include logging "too much" -- i would suggest discussing with
upstream as they may be open to improvements
- you didnt give any examples so not sure how anyone can help you



I had many email tens of megabytes long.


(there's already a request to split the report if it is long)

  In the last month, reports have been completely useless to me as they are

i sympathise - but writing local rules is always going to be needed. i
think we can do much better than what we have, but realistically it is hard
to do in this way.


If.you wanted to chamge the world, get upstream authors to agree some
standard where messges are easier to identify as routine and then logcheck
could more easily ignore that.  .... i wont hold my breath for thay

maybe it is possible - how do you define "system-level message"?

I really appreciate your work, thanks.

Sure.  And I routinely do. But I use logcheck to warn me of serious problems at the system level. Detecting user-level daemon bugs is not my priority when using logcheck. Especially because when it happens, the deluge of info hides the possible serious system-level problems that I am mostly interested into.

In the last two years I observed and reported many of those bugs, before hiding them behind a custom logcheck rule. Most were acknowledged, some were fixed.

I can find the relevant bug reports, but that's not the issue I am raising. When a random bug in gvfsd (just to mention the latest one) risks filling my root partition with multi-GB logs, and logcheck sends me hundred-MB mails full of useless stuff, that makes logcheck useless.  In the past, when I detected a bug, I kept the email for later, to report the bug when I found the time.  Now it happens way too often for me and I am seriously considering shutting it off.

Reporting bugs is voluntary work which I gladly do in my free time.  But if this subtracts work time I cannot afford it.

This is not the problem for me. Logcheck should stop logging after a configurable number of lines (for me, that would be around 100, certainly no more than 1000), because in my experience that just indicates a bug in the logging procedure of some daemon or some missing logcheck filters, and I lose my log anyway, as I do not have the time to sift through the mostly useless reported stuff.

Additionally, user-level reports should be separated from system-level ones. I am not knowledgeable enough to know how to do that if not by single crafted local rules, but if I cannot have that I will give up with logcheck. Again, I am interested in system-level serious problems, and anything that obfuscates that makes logcheck useless and worse.

Yeah, I feared that the answer would be similar :(

Those created by root-owned processes, that would be a good start.  I definitely care about Sshd messages, much less about Gvfsd ones, and even less by those generated by Telegram running over Snapd.  For some reason, the problem has vastly increased after the advent of systemctl.

Again, thank you for your work, that's very much appreciated.  And again, I know these problems have always existed, but for some reason they have increased a lot and they keep increasing.

Sincerely