Date: Mon, 3 Sep 2012 01:29:20 +0100 From: Attilio Rao <attilio@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: syslog(3) issues Message-ID: <CAJ-FndBkQDZkzb%2B2fXTvqxEgtxED9Tx_hJ5ZzPEah73PCTOARQ@mail.gmail.com> In-Reply-To: <CAGH67wRuvJu6_2Z_sNi-iJoKsVruC0dNdO8yEg0JXKox8_pWuA@mail.gmail.com> References: <CAJ-FndDeNVcEv5HRBMtQ5ZKa3zdWwt5d4fFPaoXnyV3MS31QDw@mail.gmail.com> <CAGH67wRuvJu6_2Z_sNi-iJoKsVruC0dNdO8yEg0JXKox8_pWuA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 3, 2012 at 1:20 AM, Garrett Cooper <yanegomi@gmail.com> wrote: > On Sun, Sep 2, 2012 at 4:35 PM, Attilio Rao <attilio@freebsd.org> wrote: >> Hi, >> I was trying to use syslog(3) in a port application that uses >> threading , having all of them at the LOG_CRIT level. What I see is >> that when the logging gets massive (1000 entries) I cannot find some >> items within the /var/log/messages (I know because I started stamping >> also some sort of message ID in order to see what is going on). The >> missing items are in the order of 25% of what really be there. >> >> Someone has a good idea on where I can start verifying for my syslogd >> system? I have really 0 experience with syslogd and maybe I could be >> missing something obvious. > > I'd maybe use something like rsyslog and force TCP to verify that > the messages made it to their endpoints, and if all the messages make > it to the rsyslogd daemon use tcpdump/wireshark to figure out if the > UDP datagrams (default transport layer for syslog) aren't getting > dropped on the floor. Forgot to mention: the logging is done completely locally so I don't think network should play a role here. Also, I would like to understand if I'm missing something subdle or if we actually may have a bug in syslogd. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBkQDZkzb%2B2fXTvqxEgtxED9Tx_hJ5ZzPEah73PCTOARQ>