Re: Re: rotatelogs behavior in kubernetes pod

[Andrew Athan <aathan_apache@xxxxxxxxxxxxxxxxxxxxxxxx>]

    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.
>