Bug 118760 - Errata RHSA-2004:053 breaks sar's ability to read previously-generated datafiles
Summary: Errata RHSA-2004:053 breaks sar's ability to read previously-generated datafiles
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: sysstat   
(Show other bugs)
Version: 2.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Charlie Bennett
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-19 21:37 UTC by John Caruso
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-22 22:09:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Caruso 2004-03-19 21:37:41 UTC
Description of problem:
Errata RHSA-2004:053 breaks sar's ability to read previously-
generated datafiles.

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

How reproducible:
After updating to sysstat-4.0.1-12 (as per RHSA-2004:053), run "sar -
u" on a previously-generated sar datafile.

Steps to Reproduce:
1. See above.
Actual results:
Utter gobbledygook, ending with the error message "End of system 
activity file unexpected".  Here's an example (excerpted for brevity):

# sar -u -f /var/log/sa/sa07
12:00:00 AM       CPU     %user     %nice   %system     %idle
03:51:01 PM       all    100.93      0.02      0.01      0.00
01:39:46 AM       all    102.38      0.02    102.40      0.00
09:39:28 AM       all      0.00    70172.21      0.00      0.00
04:02:35 PM       all      0.00      0.00      0.00      0.00
04:01:15 PM       all      0.00      0.00    100.00      0.00
04:00:00 PM       all      0.00      0.00      0.00      1.62
01:22:03 PM       all    205627.33    205613.30      0.00      0.00
04:00:00 PM       all      0.00      0.02      0.00      0.64
08:14:33 PM       all    100.00     99.98    100.00      0.00
04:00:00 PM       all      0.00      0.00      0.00      0.00
04:01:37 PM       all      0.00    100.85      0.00      0.00
04:00:00 PM       all      0.00    2200.00      0.00    2200.00
04:00:22 PM       all      0.00    278893978.83      0.00      0.00
04:00:00 PM       all      0.00      0.00      0.00      0.00
04:00:00 PM       all      0.00      0.00      0.00    53897628800.00
04:00:00 PM       all      0.00      0.00      0.00      0.00
04:00:00 PM       all      0.00    4800.00      0.00    175983000.00
12:54:11 AM       all      0.00    8947848433.33      0.00      0.00
08:03:42 AM         LINUX RESTART
04:00:00 PM       all      0.00    107873130000.00      0.00    
11:24:02 AM       all    303.86    1613011.30      0.00      0.00
11:32:16 PM       all      1.97    22001.44    202.18      0.00
02:37:08 AM       all    100.42     99.87     99.55      0.14
End of system activity file unexpected

(Note that it wasn't really 4pm all day long, and the system wasn't 
really rebooted....)

Expected results:
Normal sar output.

Additional info:
The sar datafiles are not corrupted--it's still possible to use the 
old sar program (e.g. from sysstat-4.0.1-2) to read them.  It's just 
that the new sar program can't read the datafiles from the previous 
version.  Either sar should be backward-compatible, or the errata 
should clearly warn that it is not backward-compatible (and 
preferably should include a copy of the old sar program to allow 
previous datafiles to be examined).

Comment 1 John Caruso 2004-04-23 20:35:48 UTC
Why is this bug not getting any attention?  I'd think that breaking 
sar's ability to read its own datafiles would be something worth 

Comment 2 John Caruso 2004-05-27 19:18:35 UTC

Comment 3 John Caruso 2004-07-06 21:44:54 UTC
Just watering my bug to see if it will grow.

Comment 4 John Newbigin 2004-07-13 01:12:06 UTC
We got errors when the number of CPUs changed (changing hyperthreading
settings).  Could be a related problem.

Comment 5 John Caruso 2004-07-13 02:25:50 UTC
I think the error you're talking about is "Cannot append data to that 
file", which happens when the number of CPUs is changed on a system.  
That's not really a bug (though it is a hassle)--it's just a result 
of the internal sar datafile requiring more fields for CPU 
information as a result of the changed CPUs, which makes sar unable 
to update the existing datafile.  Everything goes back to normal once 
sar switches to a new datafile.

That issue is almost certainly unrelated to this bug, because 1) the 
datafiles in question here were all generated on the same system, 
with no change in the number of CPUs, and 2) that issue only applies 
to attempts to append data to an existing file, and didn't impair 
sar's ability to read files generated either before or after the 
change in the number of CPUs.  The problem described in this bug is 
that the new sar executable simply cannot successfully read *any* 
datafile generated by the previous version of sar.

Comment 6 Charlie Bennett 2004-09-22 22:09:59 UTC
The upstream sysstat package routinely breaks sar datafile
compatibility, apparently with impunity.  Until we have resources to
throw at working with the upstream maintainer to clean this up using
multiple read routines selected by the embedded rev numbers of the
file the best we're going to be able to do is release note future
instances where compatibility will break by taking the update.

We will be breaking compatibility with the next updates to 2.1 and RHEL3.

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