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. The evidence I have is this: I have about 25 servers that send a static log entry every 30 minutes to my loghost. These static log entries are sent to their own destination file. This file has one of the static messages missing which indicates it was dropped. Additionally, the static entry *does* exist at the server's local log file so it was generated and sent from the remote server. Syslog-ng simply did not record it....Dropped. 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. 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. 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 10:29 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Syslog-ng to Pipe question On Thu, 20 Jul 2006 09:57:44 CDT, "SOLIS, ALEX" said:
I guess I forgot that a pipe is not a file. I thought it would just store the logs until the reader woke up again. Is the pipe is limited by system resources or something else?
The basic problem is that all the buffered data ends up sitting in memory, and usually in locked, unswappable pages. As a result, if you let a pipe have a 128K buffer, then each pipe that gets stuck can potentially nail down 128K of RAM, causing extreme memory pressure. (As an aside, making these pages swappable is often harder than you think, which is why they end up being nailed-down pages). In the Linux 2.16.18-rc1-mm1 kernel I'm running now, a writer to a pipe is allowed up to 16 4K pages (or a total of 64K) of writes before it blocks waiting for a existing reader to actually accept data - and if the reader goes away entirely, it generates an immediate SIGPIPE.
This explains the dropped stat messages but the fifo is only one destination. Why doesn't syslog-ng drop the messages destined for destination(pipe /foo/fifo/} and continue to send messages to all the other destinations successfully? I have evidence to support that some messages to all destinations are dropped. Why?
It *should* send to other destinations OK. I'm pretty sure that "dropped" gets incremented if *any* destination fails (so if 5 success, one fails, that's still a dropped++). What evidence do you have that some are being dropped entirely? 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.