Bug 578929 - March sar data was appended to February data
Summary: March sar data was appended to February data
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sysstat
Version: 5.4
Hardware: All
OS: Linux
urgent
medium
Target Milestone: rc
: ---
Assignee: Ivana Varekova
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 609819
TreeView+ depends on / blocked
 
Reported: 2010-04-01 19:08 UTC by Jeff Bastian
Modified: 2018-11-14 20:12 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the sar utility set the maximum number of days to be logged in one month too high. Consequently, data from a month were appended to data from the preceding month. With this update, the maximum number of days has been set to 25, and data from a month now correctly replaces data from the preceding month.
Clone Of: 578927
Environment:
Last Closed: 2011-07-21 10:40:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
demo program for find rounding errors (729 bytes, text/plain)
2010-04-01 19:08 UTC, Jeff Bastian
no flags Details
patch to shorten max history (329 bytes, patch)
2010-04-01 19:30 UTC, Jeff Bastian
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1005 0 normal SHIPPED_LIVE Low: sysstat security, bug fix, and enhancement update 2011-07-21 10:39:28 UTC

Description Jeff Bastian 2010-04-01 19:08:34 UTC
Created attachment 404074 [details]
demo program for find rounding errors

+++ This bug was initially created as a clone of Bug #578927 +++

Description of problem:
RHEL 4 was modified to set the max history for sar to 26 days in bug 475255.  It appears this change was never propagated to RHEL 5.  In any case, 26 days is still too long.

Given that
  1. February only has 28 days, and 
  2. that 'find ... -mtime +26' finds files that were modified 27 
     or more days ago, and 
  3. find ignores fractional days and thus has rounding errors, and
  4. the DST changes take place within sar's $HISTORY window
     (as of 2007, the second Sunday in March[1], or March 14, 2010
     this year)
then /usr/lib/sa/sa2 is only deleting files that are 28 days 
or older (not 27).

As a result, sar data from March 15 to March 28 was getting appended
to the data from February instead of replacing it.  You can see the files
from March 15 to 28 are 2x the size of normal files.
   # ls -al
   ...
   -rw-r--r--  1 root root  813552 Mar 12 23:50 sa12
   -rw-r--r--  1 root root  813552 Mar 13 23:50 sa13
   -rw-r--r--  1 root root  779664 Mar 14 23:50 sa14
   -rw-r--r--  1 root root 1626864 Mar 15 23:50 sa15
   -rw-r--r--  1 root root 1626864 Mar 16 23:50 sa16
   -rw-r--r--  1 root root 1626864 Mar 17 23:50 sa17
   ...
   -rw-r--r--  1 root root 1626864 Mar 26 23:50 sa26
   -rw-r--r--  1 root root 1626864 Mar 27 23:50 sa27
   -rw-r--r--  1 root root 1626864 Mar 28 23:50 sa28
   -rw-r--r--  1 root root  813552 Mar 29 23:50 sa29
   -rw-r--r--  1 root root  339120 Mar 30 09:50 sa30
   ...

The max needs to be 25 days to account for DST now.


Version-Release number of selected component (if applicable):
sysstat-7.0.2-3.el5

How reproducible:
every time

Steps to Reproduce:
1. run sar through Febrary and March 2010
  
Actual results:
March 15-28 data is appended to February 15-28 data

Expected results:
March data replaces February data

Additional info:

[1] http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time


Attached is a demo script to show how 'find ... -mtime +26 ...' fails to find files that are 27 days old when dealing with the DST time change on March 14, 2010.

It touches a series of files, sa10 to sa20, with timestamps from February 10 to February 20 at 23:53.  It then sets the date to March 15 and finds files that are older than 26 days.  (And finally restores the date.)

# ./find26.sh
Stopping ntpd:                                             [  OK  ]
Stopping crond:                                            [  OK  ]
Mon Mar 15 23:53:00 EDT 2010
-rw-r--r-- 1 root root 0 Feb 15 23:53 /root/timestamp/sa15
-rw-r--r-- 1 root root 0 Feb 14 23:53 /root/timestamp/sa14
-rw-r--r-- 1 root root 0 Feb 13 23:53 /root/timestamp/sa13
-rw-r--r-- 1 root root 0 Feb 12 23:53 /root/timestamp/sa12
-rw-r--r-- 1 root root 0 Feb 11 23:53 /root/timestamp/sa11
-rw-r--r-- 1 root root 0 Feb 10 23:53 /root/timestamp/sa10
Thu Apr  1 12:35:12 EDT 2010
Starting crond:                                            [  OK  ]
Starting ntpd:                                             [  OK  ]

You can see that youngest file it found was from February 15 which is 28 days old on March 15.  It does not find sa16 which is 27 days (in our thinking) even though we specified +26.  This is due to the rounding errors from find ignoring fractional parts of days.

Comment 1 Jeff Bastian 2010-04-01 19:30:22 UTC
Created attachment 404077 [details]
patch to shorten max history

Comment 9 Tomas Capek 2011-06-29 08:27:06 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the sar utility set the maximum number of days to be logged in one month too high. Consequently, data from a month were appended to data from the preceding month. With this update, the maximum number of days has been set to 25, and data from a month now correctly replaces data from the preceding month.

Comment 10 errata-xmlrpc 2011-07-21 10:40:55 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-1005.html


Note You need to log in before you can comment on or make changes to this bug.