Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 81294

Summary: keeping old sar data should be configurable.
Product: [Retired] Red Hat Raw Hide Reporter: Need Real Name <jackal>
Component: sysstatAssignee: Nils Philippsen <nphilipp>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: paul
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-27 12:26:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Need Real Name 2003-01-07 18:30:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.0.0) Gecko/20020606

Description of problem:
By default sar only keeps 7 days of data.

That should be configurable.

"/etc/cron.daily/sysstat" calls "/usr/lib/sa/sa2 -A".

/usr/lib/sa/sa2 has a hardcoded "+7" in the file.  That should be in a config
file and not the script.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. cd /var/log/sa
2. ls -al sar* |wc -l
3.
    

Actual Results:  I only had 9 days of sar data.  Curious why 9 when that find
command says 7.

But regardless, what if I wanted 3 weeks of sar data.

Expected Results:  I actually expected logrotate to handle this, but since sa2
has it hardcoded, the logs are being removed.

Additional info:

Comment 1 Nils Philippsen 2004-01-13 15:46:57 UTC
I concur with you that logrotate should handle this. I'm inclined to
remove the "rm" line from sa2 and have sysstat logrotate scripts in a
future product/version, but it would be even better if upstream had
such changes.

Comment 2 Paul Gear 2004-01-25 10:53:40 UTC
Wouldn't tmpwatch be the better tool to handle cleaning up old sar data?

Comment 3 Nils Philippsen 2004-01-25 16:43:43 UTC
Well, "further inverstigation into the matter" revealed that sysstat
won't be easily converted to work with logrotate, so for the time
being the sa2 script will remain in charge to clean up old sar data.
I'm not quite sure about whether the find command with suitable
changes to be able to configure the period of time for sar data to be
kept or a replacement tmpwatch construct is better -- but so far the
find construct has worked, so unless someone gives me a compelling
reason why using tmpwatch would be better, I'll leave it that way.

Comment 4 Nils Philippsen 2004-01-27 12:26:07 UTC
fixed in 5.0.0-0.6

Comment 5 Paul Gear 2004-02-12 10:46:47 UTC
Will this make it through to Fedora Core?