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