Re: rotatelogs behavior in kubernetes pod

[Andrew Athan <aathan_apache@xxxxxxxxxxxxxxxxxxxxxxxx>]

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