Description of problem: If there is an error in config file, log is not rotated but its deleted Version-Release number of selected component (if applicable): logrotate-3.7.4-13 How reproducible: Steps to Reproduce: RHTS: http://pkgs.devel.redhat.com/cgit/tests/logrotate/tree/Regression/bz510124-request-that-logrotate-rotate-logs-even-with?id=logrotate-CoreOS-logrotate-Regression-bz510124-request-that-logrotate-rotate-logs-even-with-1_0-4 Actual results: Not rotated log is deleted Expected results: No rotation, no deletion Additional info:
This is caused by default logrotate setting for "rotate" variable which is 0. That means no old log file is kept. So if you specify "totate 2", the option is not recognized and "rotate" variable is 0 by default. There's idea that logrotate should rotate files even when there's non-fatal error in configuration, otherwise logs could eat all the empty space on the drive which could lead to server failure. Also, normally this would not happen, because /etc/logrotate.conf sets the default value to 2. I think the best idea is to change the default value of rotate option from 0 to 2 in logrotate's code. But this should be done in upstream/Fedora at first.
We won't change the default "rotate" value in RHEL. I've cloned this bug for Fedora and will fix the default value of "rotate" directive there. I will close this bug as NOTABUG, because the initial problem is caused by bad configuration.