Logcheck devel - Apr 2006 - Bug#365121: logcheck: Fails to ignore certain pattern

Package: logcheck
Version: 1.2.43a
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have messages like these in my logs:

Apr 27 10:05:49 localhost smartd[9357]: Device: /dev/hda, SMART Prefailure
Attribute: 1 Raw_Read_Error_Rate changed from 58 to 57
Apr 27 10:05:49 localhost smartd[9357]: Device: /dev/hda, SMART Usage Attribute:
195 Hardware_ECC_Recovered changed from 58 to 57

I have this pattern in /etc/logcheck/ignore.d.workstation/local-smartd:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ smartd\[[0-9]+\]: Device:
/dev/[[:alpha:]]{3}, SMART (Prefailure|Usage) Attribute: (1|195)
(Raw_Read_Error_Rate|Hardware_ECC_Recovered) changed from (5[6-9]|6[0-3]) to
(5[6-9]|6[0-3])$

If I run the following command in a shell, it matches properly:

sudo sed -e 's/[[:space:]]*$//' /var/log/daemon.log | egrep '^\w{3}
[ :0-9]{11} [._[:alnum:]-]+ smartd\[[0-9]+\]: Device: /dev/[[:alpha:]]{3}, SMART
(Prefailure|Usage) Attribute: (1|195)
(Raw_Read_Error_Rate|Hardware_ECC_Recovered) changed from (5[6-9]|6[0-3]) to
(5[6-9]|6[0-3])$'

However, it never matches in actual logcheck runs, and those log messages always
appear in logcheck e-mails.  However, the following pattern does work on the
following log
message, and it never shows up in the e-mails:

Apr 27 21:35:49 localhost smartd[9357]: Device: /dev/hda, SMART Usage Attribute:
194 Temperature_Celsius changed from 30 to 29

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ smartd\[[0-9]+\]: Device:
/dev/[[:alpha:]]{3}, SMART Usage Attribute: 194 Temperature_Celsius changed from
([5-9]|[1-4][0-9]|50) to ([5-9]|[1-4][0-9]|50)$

I'm at a loss to explain this, so I'm filing a bug.  Forgive me if
it's my mistake.

- -- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (500,
'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages logcheck depends on:
ii  adduser          3.85                    Add and remove users and groups
ii  cron             3.0pl1-94               management of regular background p
ii  debconf [debconf 1.5.0                   Debian configuration management sy
ii  debianutils      2.15.3                  Miscellaneous utilities specific t
ii  exim4            4.61-1                  metapackage to ease exim MTA (v4) 
ii  exim4-daemon-lig 4.61-1                  lightweight exim MTA (v4) daemon
ii  grep             2.5.1.ds2-4             GNU grep, egrep and fgrep
ii  lockfile-progs   0.1.10                  Programs for locking and unlocking
ii  logcheck-databas 1.2.43a                 database of system log rules for t
ii  logtail          1.2.43a                 Print log file lines that have not
ii  mailx            1:8.1.2-0.20050715cvs-1 A simple mail user agent
ii  sysklogd [system 1.4.1-17                System Logging Daemon

logcheck recommends no packages.

- -- debconf information:
  logcheck/changes:
* logcheck/install-note:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEUaUX5+GdyTDsrJsRAhdTAKD1fBl+Zwqo/boIT5D4iFJ+WOv6rwCfe0q7
/yzxVU4JmQffsVQfVAzL6/I=qiAR
-----END PGP SIGNATURE-----

Hello Adam,

On Fri, Apr 28, 2006 at 12:16:07AM -0500, Adam Porter
wrote:
> Package: logcheck
> Version: 1.2.43a
> Severity: normal
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I have messages like these in my logs:
> 
> Apr 27 10:05:49 localhost smartd[9357]: Device: /dev/hda, SMART Prefailure
Attribute: 1 Raw_Read_Error_Rate changed from 58 to 57
> Apr 27 10:05:49 localhost smartd[9357]: Device: /dev/hda, SMART Usage
Attribute: 195 Hardware_ECC_Recovered changed from 58 to 57
> 
> I have this pattern in /etc/logcheck/ignore.d.workstation/local-smartd:
Do you also have this pattern in violations.ignore.d?  Because this string
contains the word 'failure' it will be reported anyway if it's not
ignored by
violations.ignore.d  See README.logcheck-database for more information.

I suspect this is a configuration error.  Please re-open this bug if you find
otherwise.
-- 
Todd Troxell
http://rapidpacket.com/~xtat