Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Logcheck - can't ignore liblogging-stdlog anymore

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
pycha
Posts: 2
Joined: 2017-07-17 20:03

Logcheck - can't ignore liblogging-stdlog anymore

#1 Post by pycha »

Hi everyone;
After migrating to stretch, I can't get rid of certain message via logcheck. This one:

Code: Select all

Jul 17 06:25:03 host liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="326" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
It appears in messages and syslog. I used to have my ignore rules in logcheck working, as it was rsyslog, but now I can't. The following regex is in ignore.d.server/rsyslog and ignore.d.server/liblogging-stdlog and ignore.d.server/syslog (probably too much).

Code: Select all

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ liblogging-stdlog:  \[origin software="rsyslogd" swVersion="[0-9.]+" x-pid="[[:digit:]]+"x-info="http:\/\/www\.rsyslog\.com"\] rsyslogd was HUPed$
Both configs successfully tested using logcheck test. For instance:

Code: Select all

# logcheck-test -l /var/log/messages liblogging-stdlog 
Jul 17 06:25:04 host liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="326" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
================================================================================
parsed file: /var/log/messages
used rule: 'liblogging-stdlog'
But... These lines are still being mailed to me as a warning. Am I using a wrong ignore file, or... ? :BUMP:
Any ideas / help appreciated!

creat
Posts: 2
Joined: 2017-08-03 18:47

Re: Logcheck - can't ignore liblogging-stdlog anymore

#2 Post by creat »

Same here. Does anyone have a clue?

/push

pycha
Posts: 2
Joined: 2017-07-17 20:03

Re: Logcheck - can't ignore liblogging-stdlog anymore

#3 Post by pycha »

Interesting. I though I was alone here.
I basically gave up on Stretch (for this and some more reasons) and moved back to Jessie. I haven't found a way to filter messages effectively via logcheck anymore. :(

creat
Posts: 2
Joined: 2017-08-03 18:47

Re: Logcheck - can't ignore liblogging-stdlog anymore

#4 Post by creat »

I really must say Stretch did bring up several issues for me too. Very disappointing after that flawless Wheezy -> Jessie upgrade. I am currently staying with Stretch and trying to find a workaround for every issue I encounter.

loyukfai
Posts: 11
Joined: 2012-01-09 14:00

Re: Logcheck - can't ignore liblogging-stdlog anymore

#5 Post by loyukfai »

Any update on this?

Besides rsyslogd, I'm receiving tons of samba sessions messages via logcheck as well.

Cheers.

gabe
Posts: 1
Joined: 2017-12-12 13:38

Re: Logcheck - can't ignore liblogging-stdlog anymore

#6 Post by gabe »

I was able to get rid of these logcheck messages by creating the file /etc/logcheck/ignore.d.server/local-rsyslog with the following line in it:

Code: Select all

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ liblogging-stdlog:  \[origin software="rsyslogd" swVersion="[.[:digit:]]+" x-pid="[[:digit:]]+" x-info="http://www.rsyslog.com"] rsyslogd was HUPed$
This is very similar to what the OP had attempted to do:
pycha wrote: (...)
The following regex is in ignore.d.server/rsyslog and ignore.d.server/liblogging-stdlog and ignore.d.server/syslog (probably too much).

Code: Select all

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ liblogging-stdlog:  \[origin software="rsyslogd" swVersion="[0-9.]+" x-pid="[[:digit:]]+"x-info="http:\/\/www\.rsyslog\.com"\] rsyslogd was HUPed$
... but I noticed that they didn't have a space in between...

Code: Select all

x-pid="[[:digit:]]+"
... and...

Code: Select all

x-info="...
... in their solution. My guess is that this was the problem that caused the regexp not to match.

I don't know the logcheck-test tool, so I can't say why it seems to have given an erroneous result.

I validated my new whitelisting entry by
1. provoking a HUP signal getting sent to rsyslogd in the same way that logrotate does it, by executing:

Code: Select all

# invoke-rc.d rsyslog rotate
2. checking that the log message in question was indeed written to /var/log/messages:

Code: Select all

# tail /var/log/messages         
(...)
Dec 12 14:29:02 iupiter liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="3870" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
3. Running logcheck without updating the offset so it outputs everything to STDOUT:

Code: Select all

# sudo -u logcheck logcheck -o -t
... like it says in the EXAMPLES section of the logcheck(8) man page.

This worked for me. Hope it helps someone else, too.

Post Reply