From owner-freebsd-questions Tue Dec 4 3:33: 7 2001 Delivered-To: freebsd-questions@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.2]) by hub.freebsd.org (Postfix) with ESMTP id 62AC037B405 for ; Tue, 4 Dec 2001 03:33:04 -0800 (PST) Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.2]) by prg.traveller.cz (EUnet.1022902037-17/pukvis) with ESMTP id fB4BX2i15543 for ; Tue, 4 Dec 2001 12:33:03 +0100 (CET) Date: Tue, 4 Dec 2001 12:33:02 +0100 (CET) From: Michal Mertl To: questions@freebsd.org Subject: Re: problem with apache log (newsyslog proposal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The reason you couldn't realiably compress apache's logfiles is that after renaming the log, the daemon process still writes to the old log file. Details: When you make it reopen the log (by sending USR1) new connections (ones handled with children who have already restarted) get logged to the new file. The ones which started before the signal was delivered are logged to the old file. With HUP delivered to master apache process the children are rather abruptly killed (thus all new log entries go the the new file). If you don't mind killing some downloads from your site (clients get only partial downloads) sending HUP should enable you to compress the logs. If you don't like interrupted downloads (imagine 10MB file over 56k modem interrupted at 9MB (client looses ~22 minutes) and want to compress the logs, you can either compress them separately from rotation much later (~hours to be sure) or you can rotate using some script which monitors if the old log file is still open by some children and start the compression only after there's no such children. I have small script for that if someone is interested. I think there can be flag in newsyslog to make it check if there's a process which has open the file which is to be compressed and postpone the compression until either no such child exists or some timeout is hit. If anyone thinks it's a good idea, I can try to implement that functionality. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message