On Thu, Jan 09, 2014 at 05:01:12PM +0000, Karli Sjöberg wrote:
And the rotate policy says: /etc/logrotate.d/libvirtd ## beginning of configuration section by vdsm /var/log/libvirt/libvirtd.log { rotate 100 missingok copytruncate size 15M compress compresscmd /usr/bin/xz uncompresscmd /usr/bin/unxz compressext .xz }
Now, I just handled it by changing "100" to "1000" but I think that a
I do not understand this issue, Karli. After 100 log files have been created, the oldest one should have been removed and replaced by the newest one. logrotate is expected to be called every 15 minutes, so it should not have stayed above 15M for so long. Do you see any error when running `/usr/sbin/logrotate /etc/logrotate.d/libvirtd` as root?
What the funk, it doesn´t do anything, complains nothing like it´s done what it´s supposed to, and no errors in "/var/log/messages" either...
Oh, and here´s the output: # du -h /var/log/libvirtd.log 1.1G /var/log/libvirtd.log # /usr/sbin/logrotate -d -v /etc/logrotate.d/libvirtd reading config file /etc/logrotate.d/libvirtd reading config info for /var/log/libvirt/libvirtd.log compress_prog is now /usr/bin/xz uncompress_prog is now /usr/bin/unxz compress_ext is now .xz
Handling 1 logs
rotating pattern: /var/log/libvirt/libvirtd.log 15728640 bytes (1000 rotations) empty log files are rotated, old logs are removed considering log /var/log/libvirt/libvirtd.log log does not need rotating
Really, are you sure about that?
/K
I really do not know what to say - it seems like an awkward logrotate bug. Maybe if you play with arguments a bit (avoid compression? change size?) it could be convinced to work. Otherwise it sounds like gdb time...