From owner-freebsd-security@FreeBSD.ORG Tue May 27 02:46:16 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93F04313 for ; Tue, 27 May 2014 02:46:16 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 7A821238E for ; Tue, 27 May 2014 02:46:15 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id CA01A3ACAE for ; Mon, 26 May 2014 19:46:14 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: NEVERMIND! In-Reply-To: <20140527004708.U5669@sola.nimnet.asn.au> Date: Mon, 26 May 2014 19:46:14 -0700 Message-ID: <9187.1401158774@server1.tristatelogic.com> X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:46:16 -0000 In message <20140527004708.U5669@sola.nimnet.asn.au>, Ian Smith wrote: >... might syslog trigger adhoc rotations by >newsyslog - of a particular log, not all - after learning how to measure >'stress', perhaps by rates of delta filesize, diskspace consumption etc? (Not that anyone has any reason to care what _I_ think, but...) I must say that I like that idea. The specific thing (i.e. "measurment") that should trigger such an event/action seems altogether obvious. If syslogd is writing a file and it sees that the file in question has just exceeded its allowed maximum (according to /etc/newsyslog.conf) then it is clearly time to do something about it. >Then newsyslog would only need to learn how to be so invoked? How about "kill -HUP" ? That seems to be the pro-forma thing that pretty much everything else already uses as a way to tell any given daemon that it should wake up and smell the coffee (again). Of course, *if* one were in fact going to endow syslogd with all of the intelligence necessary to read, understand, check, and act on the various max filesize specifications contained within /etc/newsyslog.conf then that would certainly prompt the question: Why not just merge the two programs into one? (Obviously, that would eliminate the need for interprocess signaling of any kind.)