[users@httpd] Re: rotatelogs behavior in kubernetes pod

[Andrew Athan <aa...@memeplex.com.INVALID>]

Sorry I hit send on this a bit too soon.

The other issue which I've confirmed is this (rotatelogs -v -e -L log -n 
3 logfile 1G) output:

Rotation time interval:                 0
Rotation size interval:        1073741824
Rotation time UTC offset:               0
Rotation based on localtime:           no
Rotation file date pattern:            no
Rotation file forced open:             no
Create parent directories:             no
Rotation verbose:                     yes
Rotation create empty logs:            no
Rotation file name: /trexo-log/logfile
Post-rotation prog:              not used
File rotation needed, reason: Open a new file
Opening file /trexo-log/logfile
Linking /trexo-log/logfile to /trexo-log/log
File rotation needed, reason: Maximum size reached
Opening file /trexo-log/logfile.1
Linking /trexo-log/logfile.1 to /trexo-log/log
Closing file /trexo-log/logfile


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"

A.


On 3/27/22 12:00 PM, Andrew Athan wrote:
>
> I have a kubernetes pod that is running a command of the form:
>
> sh -c 'python foo.py 2>&1 | rotatelogs -e -L log -n 3 logfile 1G'
>
> This works great. However, when the pod is deleted (e.g. kubectl 
> delete pod foo), kube restarts the pod.
>
> Upon restart the log and logfile are empty!!! Instead, the contents 
> should have been retained.
>
> I've tested with:
>
> sh -c '(cat 'foo';sleep 10000) 2>&1 | rotatelogs -e -L log -n 3 
> logfile 1G' &
>
> followed by kill -HUP, kill, kill -9 etc of the process and no 
> truncation/deletion of the newest log file occurs.
>
> Meanwhile, tests like:
>
> echo 'foo' | rotatelogs -v -L log -n 3 logfile 3B
> echo 'foo' | rotatelogs -v -L log -n 3 logfile 3B
> echo 'foo' | rotatelogs -v -L log -n 3 logfile 3B
>
> do *not* cause the file to rotate once it's 3B+ long.
>
> ... in brief, rotatelogs (at least with -n) seems utterly broken???
>
> A.
>
>

Re: [users@httpd] Re: rotatelogs behavior in kubernetes pod

[Eric Covener <co...@gmail.com>]

On Sun, Mar 27, 2022 at 7:13 PM Andrew Athan
<aa...@memeplex.com.invalid> wrote:
>
>
> 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?

Thanks for the report, I opened a bug and tried to summarize the
idiosyncrasies in the doc

https://bz.apache.org/bugzilla/show_bug.cgi?id=65980
https://httpd.apache.org/docs/trunk/programs/rotatelogs.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: [users@httpd] Re: rotatelogs behavior in kubernetes pod

[Andrew Athan <aa...@memeplex.com.INVALID>]

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.

Re: [users@httpd] Re: rotatelogs behavior in kubernetes pod

[Eric Covener <co...@gmail.com>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org