<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: sar works, sar -d doesn't in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342704#M13407</link>
    <description>Jared,&lt;BR /&gt;I ran into this problem as well. It was resolved when I recompiled/get a kernel version which has this option turn on.&lt;BR /&gt;&lt;BR /&gt;sar -d and iostat -d are utilities  which hooks into your kernel. There is an option in the kernel to turn this on. Is this a custome kernel?&lt;BR /&gt;</description>
    <pubDate>Wed, 28 Jul 2004 09:40:50 GMT</pubDate>
    <dc:creator>K.C. Chan</dc:creator>
    <dc:date>2004-07-28T09:40:50Z</dc:date>
    <item>
      <title>sar works, sar -d doesn't</title>
      <link>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342703#M13406</link>
      <description>I have a strange situation on one of my three Linux servers... sar -d doesn't work anymore... it used to.&lt;BR /&gt;&lt;BR /&gt;Here's the problem:&lt;BR /&gt;$ sar -d&lt;BR /&gt;Requested activities not available in file   &amp;lt;-- why getting this message?&lt;BR /&gt;&lt;BR /&gt;On all 3 Linux machines, the sa data collection stuff is running every 10 minutes (via cron):&lt;BR /&gt;&lt;BR /&gt;  $ cat /etc/cron.d/sysstat&lt;BR /&gt;  # run system activity accounting tool every 10 minutes */10 * &lt;BR /&gt;  * * * root /usr/lib/sa/sa1 1 1 # generate a daily summary of &lt;BR /&gt;  process accounting at 23:53&lt;BR /&gt;  53 23 * * * root /usr/lib/sa/sa2 -A&lt;BR /&gt;&lt;BR /&gt;Plain "sar" (or sar -A) is correctly reporting current stats for CPU, network, etc. on all 3 machines.  However, on the one server, "sa" appears to be capturing everything expected EXCEPT the disk/block device (-d) stats.  I can't figure out why.&lt;BR /&gt;&lt;BR /&gt;Just for fun, I even tried the MS-Windows-all-purpose-problem-resolver (reboot) and that didn't help.&lt;BR /&gt;&lt;BR /&gt;What do I need to do to get this server to resume capturing "sar" block device data?&lt;BR /&gt;&lt;BR /&gt;$ sar -V&lt;BR /&gt;sysstat version 4.0.3&lt;BR /&gt;&lt;BR /&gt;Red Hat Linux 7.3 Professional&lt;BR /&gt;Kernel: 2.4.20-20.7bigmem&lt;BR /&gt;&lt;BR /&gt;Also...&lt;BR /&gt;&lt;BR /&gt;"iostat -d" also comes up blank on that server:&lt;BR /&gt;$ iostat -d&lt;BR /&gt;Linux 2.4.20-20.7bigmem (test)  07/06/2004&lt;BR /&gt;&lt;BR /&gt;Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn&lt;BR /&gt;&lt;BR /&gt;Whereas, on the Production server:&lt;BR /&gt;$ iostat -d&lt;BR /&gt;Linux 2.4.20-20.7bigmem (prod)  07/06/2004&lt;BR /&gt;&lt;BR /&gt;Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn&lt;BR /&gt;dev3-0            0.00         0.01         0.00     101360          0&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;ADDITIONAL INFO:&lt;BR /&gt;I just went to the console of the problem server and noticed the following displayed 6 times:&lt;BR /&gt;cciss: cmd f7780000 has CHECK CONDITION, sense key = 0x3&lt;BR /&gt;&lt;BR /&gt;Note:&lt;BR /&gt;- It's been about *6* days since I rebooted (probably not a coincidence)&lt;BR /&gt;- I believe "cciss" is the Compaq SCSI driver&lt;BR /&gt;&lt;BR /&gt;Even though there has been no real run-time problems reported, maybe the machine just recently started experiencing some problem with a SCSI device or controller?&lt;BR /&gt;&lt;BR /&gt;HP/Compaq ProLiant DL580 G2&lt;BR /&gt;Compaq Smart Array 5312&lt;BR /&gt;&lt;BR /&gt;The equipment should still be under 3-year warranty.  Unfortunately, I don't have much experience diagnosing low-level hardware errors.  A quick Google didn't reveal much.  Anyone have a clue as to what to look at next?&lt;BR /&gt;&lt;BR /&gt;Jared</description>
      <pubDate>Tue, 27 Jul 2004 19:11:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342703#M13406</guid>
      <dc:creator>Jared Middleton</dc:creator>
      <dc:date>2004-07-27T19:11:07Z</dc:date>
    </item>
    <item>
      <title>Re: sar works, sar -d doesn't</title>
      <link>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342704#M13407</link>
      <description>Jared,&lt;BR /&gt;I ran into this problem as well. It was resolved when I recompiled/get a kernel version which has this option turn on.&lt;BR /&gt;&lt;BR /&gt;sar -d and iostat -d are utilities  which hooks into your kernel. There is an option in the kernel to turn this on. Is this a custome kernel?&lt;BR /&gt;</description>
      <pubDate>Wed, 28 Jul 2004 09:40:50 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342704#M13407</guid>
      <dc:creator>K.C. Chan</dc:creator>
      <dc:date>2004-07-28T09:40:50Z</dc:date>
    </item>
    <item>
      <title>Re: sar works, sar -d doesn't</title>
      <link>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342705#M13408</link>
      <description>My guess is that there might be some startup script which has to be enabled, to get sadc working.  Doing an `sar -d' may not be enough.</description>
      <pubDate>Thu, 29 Jul 2004 00:02:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342705#M13408</guid>
      <dc:creator>Ragu_3</dc:creator>
      <dc:date>2004-07-29T00:02:00Z</dc:date>
    </item>
    <item>
      <title>Re: sar works, sar -d doesn't</title>
      <link>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342706#M13409</link>
      <description>The kernel is: 2.4.20-20.7bigmem on both the Production server and the Test server (that has the "sar -d" problem).  The machines are nearly identically configured with minor differences that I'm sure are of no significance here.  Besides, they have all been working fine for two years, and then this one just stopped.&lt;BR /&gt;&lt;BR /&gt;I'm 99% sure the problem has to do with the console error message "cciss: cmd f7780000 has CHECK CONDITION, sense key = 0x3" which seems to relate to SCSI.  This implies that the "sar" issue is just a secondary symptom.&lt;BR /&gt;&lt;BR /&gt;I would still appreciate any advice dealing with that error though.&lt;BR /&gt;&lt;BR /&gt;Jared</description>
      <pubDate>Thu, 29 Jul 2004 02:09:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/sar-works-sar-d-doesn-t/m-p/3342706#M13409</guid>
      <dc:creator>Jared Middleton</dc:creator>
      <dc:date>2004-07-29T02:09:08Z</dc:date>
    </item>
  </channel>
</rss>

