Description of problem: The sardd files generated by sar has an incorrect date at the top. Here is an example [root@aklia955 sa]# cat /etc/redhat-release Red Hat Enterprise Linux ES release 3 (Taroon Update 9) [root@aklia955 sa]# date Thu Oct 30 16:51:56 NZDT 2008 [root@aklia955 sa]# uname -a Linux aklia955.bigcompany.co.nz 2.4.21-53.ELsmp #1 SMP Wed Nov 14 03:54:12 EST 2007 i686 i686 i386 GNU/Linux [root@aklia955 sa]# head -n 2 sar30 Linux 2.4.21-53.ELsmp (aklia955.bigcompany.co.nz) 2008-09-30 See the wrong date above ?? September 30, it is October 30 today. Version-Release number of selected component (if applicable): [root@aklia955 sa]# rpm -q sysstat sysstat-5.0.5-11.rhel3 How reproducible: A whole month worth of data shows the wrong dates at the top of each file [root@aklia955 sa]# ll sar* -rw-r--r-- 1 root root 1.6M Oct 1 23:53 sar01 -rw-r--r-- 1 root root 1.6M Oct 2 23:53 sar02 -rw-r--r-- 1 root root 1.6M Oct 3 23:53 sar03 -rw-r--r-- 1 root root 1.6M Oct 4 23:53 sar04 -rw-r--r-- 1 root root 1.6M Oct 5 23:53 sar05 -rw-r--r-- 1 root root 1.6M Oct 6 23:53 sar06 -rw-r--r-- 1 root root 1.6M Oct 7 23:53 sar07 -rw-r--r-- 1 root root 1.6M Oct 8 23:53 sar08 -rw-r--r-- 1 root root 1.6M Oct 9 23:53 sar09 -rw-r--r-- 1 root root 1.6M Oct 10 23:53 sar10 -rw-r--r-- 1 root root 1.6M Oct 11 23:53 sar11 -rw-r--r-- 1 root root 1.6M Oct 12 23:53 sar12 -rw-r--r-- 1 root root 1.6M Oct 13 23:53 sar13 -rw-r--r-- 1 root root 1.6M Oct 14 23:53 sar14 -rw-r--r-- 1 root root 1.6M Oct 15 23:53 sar15 -rw-r--r-- 1 root root 1.6M Oct 16 23:53 sar16 -rw-r--r-- 1 root root 1.6M Oct 17 23:53 sar17 -rw-r--r-- 1 root root 1.6M Oct 18 23:53 sar18 -rw-r--r-- 1 root root 1.6M Oct 19 23:53 sar19 -rw-r--r-- 1 root root 1.6M Oct 20 23:53 sar20 -rw-r--r-- 1 root root 1.6M Oct 21 23:53 sar21 -rw-r--r-- 1 root root 1.6M Oct 22 23:53 sar22 -rw-r--r-- 1 root root 1.6M Oct 23 23:53 sar23 -rw-r--r-- 1 root root 1.6M Oct 24 23:53 sar24 -rw-r--r-- 1 root root 1.6M Oct 25 23:53 sar25 -rw-r--r-- 1 root root 1.6M Oct 26 23:53 sar26 -rw-r--r-- 1 root root 1.6M Oct 27 23:53 sar27 -rw-r--r-- 1 root root 1.6M Oct 28 23:53 sar28 -rw-r--r-- 1 root root 1.6M Oct 29 23:53 sar29 -rw-r--r-- 1 root root 1.4M Oct 30 16:40 sar30 Steps to Reproduce: 1. install RHEl3 U9 and sysstat.rpm 2. look at the generated sar files 3. Actual results: One month older date shown despite having Expected results: correct date should be shown at top, not one month older date Note: tzdata and /etc/localtime is latest and [root@aklia955 sa]# rpm -q tzdata tzdata-2008b-3.el3 [root@aklia955 sa]# rpm -qi tzdata Name : tzdata Relocations: (not relocatable) Version : 2008b Vendor: Red Hat, Inc. Release : 3.el3 Build Date: Tue 27 May 2008 12:06:27 AM NZST Install Date: Tue 02 Sep 2008 01:34:56 AM NZST Build Host: js20-bc1-9.build.redhat.com Group : System Environment/Base Source RPM: tzdata-2008b-3.el3.src.rpm Size : 700229 License: GPL Signature : DSA/SHA1, Tue 27 May 2008 02:30:00 AM NZST, Key ID 219180cddb42a60e Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : Timezone data Description : This package contains data files with rules for various timezones around the world. [root@aklia955 sa]# md5sum /etc/localtime /usr/share/zoneinfo/NZ 28e3497aa0acae03edee06ed4d7dc72b /etc/localtime 28e3497aa0acae03edee06ed4d7dc72b /usr/share/zoneinfo/NZ Additional info: It does appear to be the case that sysstat joins a new file to an old one, concatenating them. Also note the entry in cron and sysstat config: [root@aklia955 sa]# cat /etc/cron.d/sysstat # run system activity accounting tool every 10 minutes */5 * * * * root /usr/lib/sa/sa1 1 1 # generate a daily summary of process accounting at 23:53 53 23 * * * root /usr/lib/sa/sa2 -A [root@aklia955 sa]# cat /etc/sysconfig/sysstat # # WARNING # This file is managed by CFEngine. # Any changes to this file will be over-written. # # How long to keep log files (days), maximum is a month HISTORY=28
Bugzilla is not a support tool The Bugzilla interface at bugzilla.redhat.com is used internally by Red Hat to process changes e.g. to Red Hat Enterprise Linux and related products, as well as by the Fedora Community to develop the Fedora Project. It is publicly available and everyone with an email address is able to create an account, file bugs, comment on bugs she or he has access to. Not all bugs are public though and not all issues filed are handled in the same way: it makes a huge difference who is behind a bug. Red Hat does monitor Bugzilla entries, and it does review them for inclusion in errata, etc. Nevertheless, as noted on the login page, Bugzilla is not a Support tool. It is an Engineering tool. It is used by Red Hat Engineering to track issues and product changes, as well as to interact with Egineering partners and other parties external to Red Hat on a technical level. So while all changes to Red Hat Enterprise Linux will at a point go through Bugzilla, this difference has a number of important consequences for general product issues filed directly through Bugzilla by external users without any privileged Engineering relationship: * Red Hat does NOT guarantee any response time or Service Level Agreement (SLA) for Bugzilla entries. - A review might happen immediately or after a time span of any length. The SLAs for Red Hat Enterprise Linux provided by Red Hat Support can be found at: https://www.redhat.com/support/policy/sla/production/ * Not all comments are publicly visible. - Red Hat Support provides customers with appropriate information excerpts and status updates from that. Red Hat does not commit to provide detailed explanations, or guidance in the context of Bugzilla. Therefore for example, Bugzilla entries might be closed as it seems without any further explanation, while Red Hat Support actually provides such explanation to customers filing through the regular support channels. * Issues coming through the regular support process, will always be prioritized higher than issues of similar impact and severity that are being filed directly through Bugzilla (unless the later get linked to customer support tickets, like this issue was). This means that they are more likely to be addressed and they are more likely to meet inclusion criteria consistent with the Red Hat Enterprise Linux life cycle policy: http://www.redhat.com/security/updates/errata/ * Work-arounds and Hotfixes if possible and appropriate are provided by Red Hat Support and through the regular support process. - This means that evenbefore a permanent fix is made available through RHN,customers who raised a high severity issue through Red Hat Support, are likely to receive an interim solution. Red Hat provides common Bugzilla access in order provide efficient development community interaction and as much transparency as possible to our customers. Our Engineers are encouraged to provide non-customer specific and non-confidential information publicly as often as possible. So while Red Hat considers issues directly entered into Bugzilla valuable feedback - may it be as comments to existing Bugzilla entries or by opening a new one; for customers encountering production issues, Bugzilla is not the right channel. Therefore we ask our customers to file requests important for their production systems via our Support service. Only for those issues, we can ensure a consistent communication. Information about our production support process can be found at: http://www.redhat.com/support/process/ Bugzilla can always be used as a supportive channel to that communication. Note: If you are a customer is participating in the Academic program and have chosen to run a Subscription without support, consequently you have no access to Red Hat Support and thus no SLA. If you think that this is insufficient for your use case, you should consider contacting the Red Hat Education specialist as described at: http://www.redhat.com/solutions/education/academic/individual/