From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED
	autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 17281 invoked from network); 17 Oct 2021 10:40:42 -0000
Received: from 4ess.inri.net (216.126.196.42)
  by inbox.vuxu.org with ESMTPUTF8; 17 Oct 2021 10:40:42 -0000
Received: from mail.9lab.org ([168.119.8.41]) by 4ess; Sun Oct 17 06:32:50 -0400 2021
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9lab.org; s=20210803;
	t=1634466759;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=q6e/VRkkRzc7JPr73aO8GIQhfV9logTz9ZcQVTP3DUw=;
	b=h3chfeAwtDG7ahIsP8xZ4yHjlg38ZAvzU4caY4QSY/i+p6uowfZM14FjeLg492k4x66Vfo
	zCKgTF1nNkIkodGxHjjGxvGLMKqAL3Ei7GTA/8/7buxMPUyCxVL1+9S2GvDdc+n5Qa+0pc
	QHLblJs+dNvTCRCBaVFZTqyhB+hbpNY=
Received: from pjw (host-185-64-155-70.ecsnet.at [185.64.155.70])
	by mail.9lab.org (OpenSMTPD) with ESMTPSA id a59f94eb (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO);
	Sun, 17 Oct 2021 12:32:39 +0200 (CEST)
Message-ID: <A5C7EA7E877C7B76A56A9998ECDBA153@9lab.org>
To: 9front@9front.org
CC: igor@9lab.org, lyndon@orthanc.ca
Date: Sun, 17 Oct 2021 12:30:02 +0200
From: igor@9lab.org
In-Reply-To: <93cde4806b45bd95@orthanc.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: scale-out replication framework XML over AJAX wrapper CSS engine configuration backend 
Subject: =?utf-8?q?Re:_[9front]_Dealing_with_log_files=E2=80=A6?=
Reply-To: 9front@9front.org
Precedence: bulk

Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>:
> igor@9lab.org writes:
> > What is the Plan9 way of dealing with growing log files such as
> > /sys/log/www and others?
> 
> Most people just leave them alone. I tend to rotate mine by hand
> about once per year.  Remember, once the files make it onto the worm
> there's no reclaiming the space anyway.  And if you rename + gzip
> them you end up burning up even more space, since you still have
> the uncompressed version in the worm.  Even though the old file
> is gone from /sys/log, it lives on forever in /n/dump.

Good point. For services with lots of log traffic (e.g. httpd) I mark
log files as temporary to avoid bothering the worm:

% ls -T /sys/log | grep '^t'
t /sys/log/auth
t /sys/log/www

…as temporary files are not backed up.

> The only reason I rotate mine is to speed up grep searches. And acme
> gets grumpy when presented with gigabyte-sized text files ...

Yeah, I have had a similar experience.

 From the feedback so far it seems that general practice is to roll
your own solution. It would be nice to have a simple tool taking
care of that chore. This could be an interesting project, a tool
with a similar feature set as multilog¹ designed the Plan9 way.

I have been looking for a project that is small and self contained…

Cheers,
Igor

¹…(https://cr.yp.to/daemontools/multilog.html)