rsyslog doesn't work with property filter 'startswith'

Bug #479592 reported by jgoubert
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Confirmed
Undecided
Unassigned
Nominated for Lucid by Aidan Lawn
Nominated for Precise by TJ
Nominated for Raring by TJ

Bug Description

Binary package hint: rsyslog

It seems that the property filter 'startswith' can't be used to filter e.g. firewall messages.
Using 'contains' works as expected.

e.g.
Nov 9 22:28:24 xxx kernel: [ 8367.076851] FIRE IN= OUT=eth0 SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=8231 DF PROTO=TCP SPT=4815 DPT=22 SEQ=2172904999 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40101040201030306)

:msg, contains, "FIRE " -/var/log/fire.log
-> works
:msg, startswith, "FIRE " -/var/log/fire.log
-> doesn't work

This issue is already mentioned in bug 450002 comment #2 .

I'm working with rsyslog 4.2.0-2ubuntu5 on (k)ubuntu 9.10 .

jgoubert (jgoubert)
description: updated
description: updated
description: updated
Revision history for this message
Aidan Lawn (aidanlawn) wrote :

Some problem for me on 10.04 (LTS) with rsyslog 4.2.0-2ubuntu8

This is a long term support release so think this bug should be moved up in importance.

Using 'contains' is a workaround but 'startswith' has significant efficiency gains when processing a lot of logs.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rsyslog (Ubuntu):
status: New → Confirmed
Revision history for this message
kit (kitrule) wrote :

I tried isequal and that doesn't work either. I assume rsyslogd is interpreting the timestamp, e.g. [ 8367.076851], as part of the message it is applying the filter to. In my case rsyslogd 4.6.4 on 11.04 (natty)

Revision history for this message
Radu Gheorghe (radu0gheorghe) wrote :

The problem seems to be that there's a leading space in the message.

:msg, startswith, " FIRE " -/var/log/fire.log
-> should work (at least for me it does)

I've seen on the debug log (rsyslog -d -n), this thing:
----
var '$msg': ' message goes here'
----

Which, via Google, lead me here: http://www.rsyslog.com/log-normalization-and-the-leading-space/

Where it says "The answer is, that messages are processed as RFC3164. In this RFC it is defined, that everything after the “:” of the syslog header is to be considered as the message. Thus, the message has a leading space now."

Revision history for this message
Haw Loeung (hloeung) wrote :

I can confirm that Radu Gheorghe (radu0gheorghe) is correct and have had to use the following template to discard the leading whitepsace.

  $template ApacheLogFormat,"%msg:2:10000%\n"

Revision history for this message
TJ (tj) wrote :

This is caused by the intersection of two distinct 'features'.

I'm investigating 12.04 Precise LTS with rsyslog version 5.8.6.

Firstly, a caution: the documentation for the imklog module on the rsyslog web-site is not version-specific and therefore cannot be relied upon for clear accurate information about the version carried by Ubuntu.

The issues are:

1. the imklog module receives Linux kernel log messages. The kernel prefixes those log messages with a time-stamp of the form "[174766.200834] ...". This is rsyslog's %msg% property.

2. The "startswith" compare-operator "Checks if the value is found exactly at the beginning of the property value".

So, when receiving kernel log messages they begin with a time-stamp which prevents use of the "startswith" operator to match on a log message prefix.

In version 7.3.4 of rsyslog released 7 December 2012 the imklog module has the operator "KeepKernelTimeStamp" which can be set to "off" to drop the time-stamps.

Changed in rsyslog (Ubuntu):
assignee: nobody → Wayne Witzel III (wwitzel3)
status: Confirmed → Fix Committed
status: Fix Committed → Confirmed
assignee: Wayne Witzel III (wwitzel3) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.