NetBSD Problem Report #48460

From www@NetBSD.org  Fri Dec 20 00:04:06 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4745AA63C4
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 20 Dec 2013 00:04:06 +0000 (UTC)
Message-Id: <20131220000403.DFA1EA6463@mollari.NetBSD.org>
Date: Fri, 20 Dec 2013 00:04:03 +0000 (UTC)
From: dhgutteridge@sympatico.ca
Reply-To: dhgutteridge@sympatico.ca
To: gnats-bugs@NetBSD.org
Subject: Minor man page enhancement for newsyslog(8)
X-Send-Pr-Version: www-1.0

>Number:         48460
>Category:       bin
>Synopsis:       Minor man page enhancement for newsyslog(8)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          closed
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 20 00:05:01 +0000 2013
>Closed-Date:    Fri Dec 20 10:14:39 +0000 2013
>Last-Modified:  Fri Dec 20 17:05:00 +0000 2013
>Originator:     David H. Gutteridge
>Release:        6.99.28
>Organization:
>Environment:
N/A
>Description:
The newsyslog(8) man page doesn't note that a value of 0 in the ngen
field disables the deletion of archived log files for that entry. I
thought that should be clarified given there's more than one possible
behaviour one could guess could happen (i.e., it could not keep any
archived log files instead).

(From looking at the code, any negative value supplied for that field
would have the same effect, though it would fall through the initial
check for zero and simply fail to unlink any files.)

>How-To-Repeat:
Read the man page and wonder what an ngen value of 0 would do.
>Fix:
--- newsyslog.8.orig	2013-12-19 18:50:47.000000000 -0500
+++ newsyslog.8	2013-12-19 18:58:53.000000000 -0500
@@ -133,7 +133,8 @@
 Specify the mode of the log file and archives.
 .It Ar ngen
 Specify the number of archive files to be kept
-besides the log file itself.
+besides the log file itself. A value of 0 disables the deletion of
+any archive files during log rotation.
 .It Ar size
 When the size of the log file reaches
 .Ar size

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Fri, 20 Dec 2013 10:14:39 +0000
State-Changed-Why:
Committed, thanks.


From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/48460 CVS commit: src/usr.bin/newsyslog
Date: Fri, 20 Dec 2013 10:14:25 +0000

 Module Name:	src
 Committed By:	wiz
 Date:		Fri Dec 20 10:14:25 UTC 2013

 Modified Files:
 	src/usr.bin/newsyslog: newsyslog.8

 Log Message:
 Document what ngen 0 does.
 From David Gutteridge in PR 48460.


 To generate a diff of this commit:
 cvs rdiff -u -r1.37 -r1.38 src/usr.bin/newsyslog/newsyslog.8

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David H.Gutteridge <dhgutteridge@sympatico.ca>
To: gnats-bugs@NetBSD.org,
 wiz@NetBSD.org
Cc: 
Subject: Re: bin/48460 (Minor man page enhancement for newsyslog(8))
Date: Fri, 20 Dec 2013 10:54:43 -0500

 On 2013-12-20, at 5:14 AM, wiz@NetBSD.org wrote:

 > Synopsis: Minor man page enhancement for newsyslog(8)
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: wiz@NetBSD.org
 > State-Changed-When: Fri, 20 Dec 2013 10:14:39 +0000
 > State-Changed-Why:
 > Committed, thanks.
 > 

 This is very embarrassing, but I got it backwards; I missed a
 reference in the code further down. An ngen value of zero doesn't
 preserve any log files at all, which is more intuitive. Whether
 that's worth documenting, I don't know. (The reason I was looking at
 this was because I was trying to see how to indefinitely preserve
 archived chunks of a log file, where storage isn't an issue. It
 appears -- unless I've misread something again -- that any negative
 value supplied will have that effect, but I'm not sure that's by
 design, rather it could be undocumented behaviour that should stay
 that way...)

 (Another piece of trivia is that if one reduces the number of archive
 files specified to retain, it seems it doesn't clean up any past the
 new expected count of them. I can see why that's the case, given the
 complexity of trying to guess past that point.)

 I think this should just be reverted... Sorry for wasting your time!
 I can try and redeem myself on this one by spending more time with it
 and see if I find anything of note for the man page.

 Dave

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/48460 CVS commit: src/usr.bin/newsyslog
Date: Fri, 20 Dec 2013 17:01:39 +0000

 Module Name:	src
 Committed By:	wiz
 Date:		Fri Dec 20 17:01:39 UTC 2013

 Modified Files:
 	src/usr.bin/newsyslog: newsyslog.8

 Log Message:
 Revert previous, it was wrong.
 From David H. Gutteridge in PR bin/48460.


 To generate a diff of this commit:
 cvs rdiff -u -r1.38 -r1.39 src/usr.bin/newsyslog/newsyslog.8

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Thomas Klausner <wiz@NetBSD.org>
To: "David H.Gutteridge" <dhgutteridge@sympatico.ca>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/48460 (Minor man page enhancement for newsyslog(8))
Date: Fri, 20 Dec 2013 18:02:23 +0100

 On Fri, Dec 20, 2013 at 10:54:43AM -0500, David H.Gutteridge wrote:
 > This is very embarrassing, but I got it backwards; I missed a
 > reference in the code further down. An ngen value of zero doesn't
 > preserve any log files at all, which is more intuitive. Whether
 > that's worth documenting, I don't know. (The reason I was looking at
 > this was because I was trying to see how to indefinitely preserve
 > archived chunks of a log file, where storage isn't an issue. It
 > appears -- unless I've misread something again -- that any negative
 > value supplied will have that effect, but I'm not sure that's by
 > design, rather it could be undocumented behaviour that should stay
 > that way...)
 > 
 > (Another piece of trivia is that if one reduces the number of archive
 > files specified to retain, it seems it doesn't clean up any past the
 > new expected count of them. I can see why that's the case, given the
 > complexity of trying to guess past that point.)
 > 
 > I think this should just be reverted... Sorry for wasting your time!
 > I can try and redeem myself on this one by spending more time with it
 > and see if I find anything of note for the man page.

 Ok, I've reverted it, thanks for letting me know.

 If you can't find anything to improve in this man page, there are lots
 of others ;)
  Thomas

>Unformatted:

Home	PR Database Search