logrotate configuration seems wrong

John Meinel john at arbash-meinel.com
Mon Sep 15 05:13:05 UTC 2014


So I was testing scaling today which generally generates huge volumes of
logging (I actually wanted to keep it because I used it for seeing how
everything went, but I understand why we are rotating the logs.)

However, I found this as it was running:
# ls -sh /var/log/juju
total 909M
323M all-machines.log
4.0K ca-cert.pem
4.0K logrotate.conf
4.0K logrotate.run
301M machine-0-2014-09-15T05-02-27.486.log
301M machine-0-2014-09-15T05-06-53.779.log
 80M machine-0.log
4.0K rsyslog-cert.pem
4.0K rsyslog-key.pem

Notice that there is only 1 all-machines.log that is 300MB in size, while
there are 2 machine-0 logs.

And when I track down the various configuration files, I find
# cat logrotate.conf

/var/log/juju/all-machines.log {
    size 512M
    # don't move, but copy-and-truncate so the application won't have to be
    # told that the file has moved.
    copytruncate
    # maximum of one old file
    rotate 1
    # counting old files starts at 1 rather than 0
    start 1
    # use compression
    compress
}


I have the feeling that someone didn't realize "rotate 1" means only keep
the original log file. As in, there are *no* backup files.

Did the person who implemented this actually test it?

Did we ever fix things so that "juju debug-log" doesn't become immediately
useless once you reach the rotate threshold (that it can look in the backup
log files)?

I can understand not fixing debug-log, but I'm a bit surprised that our
idea of "all-machines.log needs to be rotated" became "all-machines.log
needs to be truncated".

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140915/fb13ac9c/attachment.html>


More information about the Juju-dev mailing list