Bug 1143916

Summary: Glusterfs' entries for logrotate overrule all logrotate's settings
Product: [Fedora] Fedora Reporter: Bert DeKnuydt <Bert.Deknuydt>
Component: glusterfsAssignee: Lalatendu Mohanty <lmohanty>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 20CC: barumuga, humble.devassy, joe, jonathansteffan, kkeithle, lmohanty, mrsam, ndevos, silas
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-05-20 17:15:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bert DeKnuydt 2014-09-18 09:09:29 UTC
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.

Comment 1 Henrique Martins 2014-10-06 15:57:01 UTC
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.

Comment 2 Kaleb KEITHLEY 2014-10-27 13:44:47 UTC
*** Bug 1157160 has been marked as a duplicate of this bug. ***

Comment 3 Lalatendu Mohanty 2014-10-29 19:44:51 UTC
Issue got fixed in gluster upstream at http://review.gluster.org/8994.

Comment 4 Lalatendu Mohanty 2014-11-07 19:53:00 UTC
This will be fixed with glusterfs 3.5.3 packages