[syslog-ng] Syslog-ng to Pipe question

[SOLIS, ALEX]

Sounds good to me.  Ill give that a try.  Like I said, the reader
program is designed to terminate if a certain number of alerts arrive in
a certain period of time.  If the reader program trips off, I would like
to keep it that way until a human can interpret the conditions and
prevent syslog-ng from dropping messages.

I think first though I need to verify that messages to other destination
were/are actually getting dropped.  I think I saw somewhere in the list
that syslog-ng 2.0 has a new more verbose stats messages, is this true?
If it is I think I will upgrade so testing will yield more information;
particularly which destination is dropping messages. :)

Thanks for the Advice!!!

Alex


-----Original Message-----
From: syslog-ng-bounces at lists.balabit.hu
[mailto:syslog-ng-bounces at lists.balabit.hu] On Behalf Of
Valdis.Kletnieks at vt.edu
Sent: Thursday, July 20, 2006 11:30 AM
To: Syslog-ng users' and developers' mailing list
Subject: Re: [syslog-ng] Syslog-ng to Pipe question

On Thu, 20 Jul 2006 11:08:49 CDT, "SOLIS, ALEX" said:
> Could you elaborate on the SIGPIPE?  Is there a way I can generate one
> if my reader goes away with my current kernel (2.6.10-gentoo)?  It
seems
> to me that I am going to need to implement some sort of solution and I
> think killing the PIPE until administrator intervention is a good one.

Actually, it isn't something you need to generate - your reader program
crashes, the kernel notices, and hands the process at the other end
(syslog-ng) a SIGPIPE free of charge.  

> I recognize it is possible that since I am using UDP as a transport,
> syslog-ng might have never received the message.  I consider this
highly
> unlikely since I have not experience a UDP related missed syslog
message
> in over a year.

Hold that thought for a moment... :)

> Thanks so much for your help Valdis!  Maybe you can suggest a solution
> for me?  I cant afford to drop messages if my reader dies.  I need a
way
> to either kill the pipe, extend the pipe, or tell syslog-ng to do
> something.  Re-starting the reader is not an option because it most
> probably terminated due to an alerting flood, which we want to avoid.

(I'll skip over "fix the reader so it doesn't crash" as "too obvious" :)

On the other hand, you *do* eventually need to re-start that reader, or
you won't get any further data read.  And presumably, you want that
data,
or you wouldn't have started that destination in the first place....

Getting back to that held thought... If you're in the muddle of a flood
of
messages, it *is* possible to have a UDP packet dropped (and if
anything,
that's the time it's *most* likely to happen).

One possibility is to set the destination up as a *named pipe*, as
follows:

1) mknod p /tmp/your_pipe_here

2) specify /tmp/your_pipe_here as a destination *FILE* for syslog-ng
(yes,
this will work...)

3) Someplace else, start your reader program with the pipe as standard
*input*:

/usr/local/sbin/rdr_prog < /tmp/your_pipe_here

If the reader goes away, syslog-ng will get the usual 'unable to write'
results back, and retry opening the file(pipe) every minute or so.  Then
in a cron job that runs every few minutes, you can do something like:

#!/bin/bash
if ! killall -0 rdr_prog 
then
	/usr/local/sbin/rdr_prog < /tmp/your_pipe_here > /dev/console
2>&1 &
fi

And with any luck at all, the message flood that killed your reader will
be
over by the time the cron job runs, so you only miss a few minutes...



This e-mail contains Omaha Public Power District's confidential and proprietary information and is for use only by the intended recipient.  Unless explicitly stated otherwise, this e-mail is not a contract offer, amendment, nor acceptance.  If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.