From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 22 03:15:58 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423D2106564A for ; Tue, 22 Feb 2011 03:15:58 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id DEB448FC0A for ; Tue, 22 Feb 2011 03:15:57 +0000 (UTC) Received: (qmail 28015 invoked by uid 399); 22 Feb 2011 02:47:55 -0000 Received: from router.ka9q.net (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 22 Feb 2011 02:47:55 -0000 X-Originating-IP: 75.60.237.91 X-Sender: dougb@dougbarton.us Message-ID: <4D6323D9.5090500@dougbarton.us> Date: Mon, 21 Feb 2011 18:47:53 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110129 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: multipart/mixed; boundary="------------000906090401000304050905" X-Mailman-Approved-At: Tue, 22 Feb 2011 03:22:36 +0000 Cc: Subject: Problem with etc/periodic/daily/310.accounting 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: Tue, 22 Feb 2011 03:15:58 -0000 This is a multi-part message in MIME format. --------------000906090401000304050905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was looking over etc/periodic/daily/310.accounting on a system that is very tight on space in /var, and I think that at minimum there is a race, and at best there is a pretty serious inefficiency. Right now after rotating the old logs the script does this: cp -pf acct acct.0 || rc=3 sa -s $daily_accounting_flags || rc=3 case "$daily_accounting_compress" in [Yy][Ee][Ss]) gzip -f acct.0 || rc=3;; esac To start with, the cp is a problem on a space-constrained system especially when the log is very large. However I think that doing it this way also introduces a race where events that are logged between the cp and the sa run are not backed up in acct.0. ITSM that the proper procedure is: mv acct acct.0 || rc=3 case "$daily_accounting_compress" in [Yy][Ee][Ss]) gzip --keep -f acct.0 || rc=3;; esac sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3 Can anyone see why that would be wrong? If there is no objection, I'll be committing the attached patch. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ --------------000906090401000304050905 Content-Type: text/plain; name="310.accounting.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="310.accounting.diff" Index: 310.accounting =================================================================== --- 310.accounting (revision 218864) +++ 310.accounting (working copy) @@ -41,13 +41,15 @@ m=$n n=$(($n - 1)) done - cp -pf acct acct.0 || rc=3 - sa -s $daily_accounting_flags || rc=3 + mv acct acct.0 || rc=3 + case "$daily_accounting_compress" in [Yy][Ee][Ss]) - gzip -f acct.0 || rc=3;; + gzip --keep -f acct.0 || rc=3;; esac + + sa -s $daily_accounting_flags acct.0 && unlink acct.0 || rc=3 fi;; *) rc=0;; --------------000906090401000304050905--