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@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Valdis.Kletnieks@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.