From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 3 08:37:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A658106564A; Mon, 3 Sep 2012 08:37:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 534BC8FC15; Mon, 3 Sep 2012 08:37:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2E31A46E81; Mon, 3 Sep 2012 04:37:08 -0400 (EDT) Date: Mon, 3 Sep 2012 09:37:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Hackers Subject: Re: syslog(3) issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 08:37:14 -0000 On Mon, 3 Sep 2012, Attilio Rao wrote: > 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. syslog(3)/syslogd(8) use datagram sockets for both local and networked logging, and it is possible for those datagram sockets to fill and drop messages. I'm not sure if we have per-socket counters that can easily be queried by syslogd, but if we do, it might be beneficial to have syslogd wake up once a second and check to see if the counters have changed -- if they have, inject a log message indicating how many messages were dropped in the last $epsilon. If we don't have counters along those lines, it might make sense to add them. We might also find that it is appropriate to tune up the limits if they no longer seem sensible in the current world order -- they may have late 1980s/early 1990s values (or they may not). Robert