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
=:->
-- 
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Reply via email to