Would you please update the man page so the next poor slob doesn't lose
important traces when their modern container environment restarts and
their logs are lost as a result of using -n?
I'd do it myself but I don't have the tooling set up, nor do I know how
to submit patches to Apache projects, and my time is limited.
(Believe it or not rotatelogs is one of the only pre-built pipe log
rotation tools that comes up when searching for such a thing.)
Separately:
Arguably the following "correct" behavior is backwards compatible with
the existing behavior: Retain only a limited amount of trace-like
output, would be to continue appending to the newest file of any
existing logfiles matching the [1...n] filenames; or if that fails, only
then open and truncate the (i+1)%n'th one, where i = largest n from
existing files.
The existing behavior is also arguably wrong. Once your base file is
full, whether or not you've rotated through again, you end up with
whatever's in that file, plus a truncated .1 file: There is then no
clear relationship between the last line of the base file and the first
line of the .1 file.
Thanks for looking.
Andrew
On 3/27/22 12:28 PM, Eric Covener wrote:
In other words, rotatelogs is finding the large logfile, and then creating logfile.1 ...
but if logfile.1 already exists it's blown away. It doesn't "continue where it left
off"
-n looks to intentionally/explicitly treat the initial file and
subsequent rotations differently, as you say above. The latter are
truncated when opened.
It's not captured in the manual, but the intent behind -n was
retaining a limited amount of trace-like output. Misguided or not,
this is the behavior for quite some time of this relatively obscure
option.
