Okay,

I started up rsyslog with debugging twice. Once with queuing turned on, once without. I immediately ran the test script that sends one message to each facility at each severity and then killed the rsyslog daemon ... so the results between the two *should* be fairly identical, there is minimal additional syslog traffic on the machine at this time.

Immediately, I noticed:

host: /tmp> grep -i logserver rsyslog.queue.debug  | wc -l
173
host: /tmp> grep -i logserver rsyslog.noqueue.debug  | wc -l
142

As I suspected, more logs were being sent to the logserver with queuing turned on (ie. they weren't getting filtered). I've posted the debug logs here:
http://spark.colorado.edu/rsyslog/

I am somewhat new to rsyslog, and I've certainly never trolled through a debug file. I may have a chance to take a look tonight, but given my familiarity with the software it may be difficult to zero in on anything.

Thanks!

-- Eric

Rainer Gerhards wrote:
Could you create a debug log with such a message? It should tell us what is
going on. Instructions:

http://www.rsyslog.com/doc/troubleshoot.html

Rainer

-----Original Message-----
From: rsyslog-boun...@lists.adiscon.com [mailto:rsyslog-
boun...@lists.adiscon.com] On Behalf Of Eric Schoeller
Sent: Thursday, February 10, 2011 7:11 PM
To: rsyslog-users
Subject: Re: [rsyslog] Queuing subsystem and message filtering

Oh, sorry my mail client must have munged those lines. I am getting a
clean start-up and shutdown:

Feb 10 11:02:07 host rsyslogd: [origin software="rsyslogd"
swVersion="5.6.3" x-pid="15452" x-info="http://www.rsyslog.com";]
exiting
on signal 15.
Feb 10 11:02:07 host kernel: Kernel logging (proc) stopped.
Feb 10 11:02:07 host rsyslogd: [origin software="rsyslogd"
swVersion="5.6.3" x-pid="15884" x-info="http://www.rsyslog.com";] start
Feb 10 11:02:07 host kernel: imklog 5.6.3, log source = /proc/kmsg
started.

Here is a better representation of it:

http://pastebin.com/M6Lwseqr

the two '/var/log/everything_to_send' where being used for debugging. I
actually stacked both of those lines directly above the
@logserver.colorado.edu line, and that's when I noticed a discrepancy
between what was getting logged to everything_to_send and
everything_to_send2. Then I bumped those lines back up above the
queuing
directives and observed that debug (and a bunch of other filtered
messages) were making it to logserver.colorado.edu.

-- Eric

Rainer Gerhards wrote:
HAve you checked for any error messages from rsyslogd inside your
logs (do
you even log them -- many distros don't do by default :-(( )

I am asking because the snippet looks syntactically wrong (then on a
separate
line).

Rainer


-----Original Message-----
From: rsyslog-boun...@lists.adiscon.com [mailto:rsyslog-
boun...@lists.adiscon.com] On Behalf Of Eric Schoeller
Sent: Thursday, February 10, 2011 4:51 PM
To: rsyslog@lists.adiscon.com
Subject: [rsyslog] Queuing subsystem and message filtering

Hello list,

I recently tried out message queuing using rsyslog-5.6.3.

Take the following config snippet:

...
# Throw out all messages with debug severity before we log to the
network
if $syslogseverity-text == 'debug'
then ~

$WorkDirectory /var/spool/rsyslog       # location for work (spool)
files
$ActionQueueType LinkedList             # use asynchronous
processing
$ActionQueueFileName logserver-queue    # set file name, also
enables
disk mode
$ActionResumeRetryCount -1              # infinite retries on insert
failure
$ActionQueueSaveOnShutdown on           # save in-memory data if
rsyslog
shuts down

# Log anything that hasn't been specifically filtered out with '~'
to
logserver
*.*                                     @logserver.colorado.edu
...

In this scenario I would assume that all messages with the severity
of
debug don't get logged over the network to 'logserver.colorado.edu'.
But
they do. If I comment all 5 of the directives that activate queuing,
the
debug messages are no longer logged over the network.

Is this by design, and if so could someone explain why? Is this a
bug?
Do I have a configuration problem?

Thanks!

Eric Schoeller
University of Colorado, Boulder
Information Technology Services

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Reply via email to