From owner-freebsd-isp Thu May 20 16:22:14 1999 Delivered-To: freebsd-isp@freebsd.org Received: from hera.webcom.com (hera.webcom.com [209.1.28.42]) by hub.freebsd.org (Postfix) with ESMTP id 04C4D1586C for ; Thu, 20 May 1999 16:22:12 -0700 (PDT) (envelope-from graeme@echidna.com) Received: from kigal.webcom.com (kigal.webcom.com [209.1.28.57]) by hera.webcom.com (8.9.1/8.9.1) with SMTP id QAA00387; Thu, 20 May 1999 16:22:11 -0700 Received: from [204.143.69.23] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 27972773; Thu May 20 16:18 PDT 1999 Message-Id: <3744C34B.409E@echidna.com> Date: Thu, 20 May 1999 19:22:03 -0700 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 2.02 (Win16; I) Mime-Version: 1.0 To: James Wyatt Cc: Roger Marquis , freebsd-isp@freebsd.org Subject: Re: Web Statistics break up program. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org James Wyatt wrote: > > On Tue, 18 May 1999, Roger Marquis wrote: > > This will create an archived logfile (http.site.May_1999) and erase > > the original without needing to kill -1 the httpd. > > > > #!/bin/sh - > > LOGDIR=/var/log > > ARCDIR=/var/log/oldlogs > > DAY=`date | awk '{ OFS="_" ;print $2,$6}' ` > > for log in $LOGDIR/http* ; do > > cp $log $ARCDIR/${log}.${DAY} > > chmod 440 $ARCDIR/${log}.${DAY} > > cp /dev/null $log > > done > > And on several of our servers will miss some events we need in the log. > Any entries that fall between the two 'cp' commands get zapped. (btw: It > would be better to move the 'chmod' after the second 'cp' to reduce this) > These events will be gone forever and may represent billable or auditable > content. beware... What is wrong with signalling the server once a day? A 'kill -1' causes Apache to immediately kill off all the server children, aborting transfers in progress - not too good for a busy commerce server. In addition, new children must be spawned, causing a hiatus of a few seconds (sometimes appreciably more) with incoming requests piling up until full performance is restored. A 'kill -1' also zeros out server statistics. Doing all this seems a bit silly just to rotate log files. The server I run almost never has a moment without at least several transfers in progress. Some are possibly of large files, and aborting those transfers is particularly annoying to users. But aborting a secure server transaction really looks bad, especially if the server state has been changed and the user fails to get the appropriate response (e.g., an order has been accepted, but no confirmation appears, just some "connection lost" type message). Also, what happens to CGI processes in progress? At the same time, I don't really like the way 'kill -USR1' works. Someone suggested using the Apache rotatelogs program, and I will be looking into that again (I had previously tried it, but was disatisfied with the limited flexibility, e.g., daily rotates occurring at around 00:00:00 UTC). With all the features and flexibility built into Apache, it seems disappointing that the log rotation issue doesn't seem to have been addressed better. -- Graeme Tait - Echidna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message