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.
