Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The file '/etc/logrotate.d/glusterfs-georep' sets variables out of its own scope, so overrules global logrotate settings. User loses functionality of most of his settings in /etc/logrotate.conf so logrotate is crippled. Version-Release number of selected component (if applicable): glusterfs-3.5.2-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Install the glusterfs package 2. Try 'logrotate -d -v /etc/logrotate.conf' 3. Actual results: See that all your rotated logfiles will be compressed. Expected results: No global overruling from one package for _all_ your logfiles. Additional info: The wrong file states ---snip--- rotate 52 missingok compress delaycompress notifempty <file> { ... } ---snip--- Which is not scoped, so global; i.e. it sets the default rotate to 52 weeks, compresses everything etc. Meant was probably <file1> <file2> <file3> { rotate 52 missingok compress delaycompress notifempty ... } Additionally, I think that 52,, i.e. one year is rather too much. No other package I know of does so. Why not simply leave it to the user, and take his defaults (usually 4, i.e. one month)? Same story for 'compress' / 'delaycompress'. The other two logrotate entries of glusterfs do follow these rules.
This has been bugging me for a while, looked at bugzilla for logrotate bugs, but never proceeded any further. This morning I manually ran logrorate with -d and found the glusterfs (clusterfck I'd say) problem. This should be fixed, and yes, 52 weeks seems rather high, specially for (the majority of) people that don't even use this thing. I don't have a single log file from glusterfs.
*** Bug 1157160 has been marked as a duplicate of this bug. ***
Issue got fixed in gluster upstream at http://review.gluster.org/8994.
This will be fixed with glusterfs 3.5.3 packages