<?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: STM in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831320#M88937</link>
    <description>Gopi,&lt;BR /&gt;&lt;BR /&gt;If you respond with some more detail on your configuration, perhaps we can help.  What are the versions of the OS, Predictive, and STM?  What is your hardware platform (with STM and Predictive, this can be important), I/O structure (array/SAN with many paths?) and what is your patch level?&lt;BR /&gt;&lt;BR /&gt;It might help to attach the output of an 'swlist -l product' command.&lt;BR /&gt;&lt;BR /&gt;You might try the following to see if things normalize:&lt;BR /&gt;&lt;BR /&gt;/sbin/init.d/diagnostic stop&lt;BR /&gt;rm /var/stm/data/diaglogd_hold_list&lt;BR /&gt;touch /var/stm/data/diaglogd_hold_list&lt;BR /&gt;/sbin/init.d/diagnostic start&lt;BR /&gt;&lt;BR /&gt;This will get rid of the runaway file, but not the root cause, which could be hardware or a problem with the diagnostic subsystem.  (This is why the system config info is important.)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Dave</description>
    <pubDate>Wed, 23 Oct 2002 01:49:08 GMT</pubDate>
    <dc:creator>Dave Unverhau_1</dc:creator>
    <dc:date>2002-10-23T01:49:08Z</dc:date>
    <item>
      <title>STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831316#M88933</link>
      <description>I have STM running on my production system /var file system is getting full always. /var/stm/data/diaglogd_hold_list is a huge file.&lt;BR /&gt;&lt;BR /&gt;How can i stop/disable STM ?&lt;BR /&gt;Is it OK to Stop STM ?&lt;BR /&gt;Can i Delete this file ?&lt;BR /&gt;&lt;BR /&gt;Thank you&lt;BR /&gt;Gopi</description>
      <pubDate>Wed, 23 Oct 2002 01:02:36 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831316#M88933</guid>
      <dc:creator>Gopinath rao_1</dc:creator>
      <dc:date>2002-10-23T01:02:36Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831317#M88934</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;I would not be disabling the diagnostic daemon. This daemon also sends messages to 'dmesg' and /var/adm/syslog/syslog.log.&lt;BR /&gt;&lt;BR /&gt;The first thing I would check is to see how much data is being collected over what period. If some of the information is 6 months old, then there is little reason to keep it. Also have a look at the list of files presented at the tail of the 'diagmond' man page. Some of these are configurable, so this may be a place to check.&lt;BR /&gt;&lt;BR /&gt;HTH&lt;BR /&gt;Michael</description>
      <pubDate>Wed, 23 Oct 2002 01:22:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831317#M88934</guid>
      <dc:creator>Michael Tully</dc:creator>
      <dc:date>2002-10-23T01:22:06Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831318#M88935</link>
      <description>A second to Michael's recommendations. If the directory is filling up, you have a serious hardware problem and your system may be ready to crash. Best check those logs and take action. The logs won't grow very fast if there are no problems.</description>
      <pubDate>Wed, 23 Oct 2002 01:31:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831318#M88935</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2002-10-23T01:31:01Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831319#M88936</link>
      <description>Yes we had a bad disk which was replaced and the problem is fixed now. &lt;BR /&gt;how can i read the contents of the /daiglogd_hold_list.&lt;BR /&gt;&lt;BR /&gt;I have not used STM ? &lt;BR /&gt;can make this a zero byte file for now.&lt;BR /&gt;&lt;BR /&gt;Thank you&lt;BR /&gt;Gopi&lt;BR /&gt;</description>
      <pubDate>Wed, 23 Oct 2002 01:37:21 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831319#M88936</guid>
      <dc:creator>Gopinath rao_1</dc:creator>
      <dc:date>2002-10-23T01:37:21Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831320#M88937</link>
      <description>Gopi,&lt;BR /&gt;&lt;BR /&gt;If you respond with some more detail on your configuration, perhaps we can help.  What are the versions of the OS, Predictive, and STM?  What is your hardware platform (with STM and Predictive, this can be important), I/O structure (array/SAN with many paths?) and what is your patch level?&lt;BR /&gt;&lt;BR /&gt;It might help to attach the output of an 'swlist -l product' command.&lt;BR /&gt;&lt;BR /&gt;You might try the following to see if things normalize:&lt;BR /&gt;&lt;BR /&gt;/sbin/init.d/diagnostic stop&lt;BR /&gt;rm /var/stm/data/diaglogd_hold_list&lt;BR /&gt;touch /var/stm/data/diaglogd_hold_list&lt;BR /&gt;/sbin/init.d/diagnostic start&lt;BR /&gt;&lt;BR /&gt;This will get rid of the runaway file, but not the root cause, which could be hardware or a problem with the diagnostic subsystem.  (This is why the system config info is important.)&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Regards,&lt;BR /&gt;&lt;BR /&gt;Dave</description>
      <pubDate>Wed, 23 Oct 2002 01:49:08 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831320#M88937</guid>
      <dc:creator>Dave Unverhau_1</dc:creator>
      <dc:date>2002-10-23T01:49:08Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831321#M88938</link>
      <description>Gopi,&lt;BR /&gt;&lt;BR /&gt;(I was formulating my reply and didn't see the previous responses before transmitting mine.)&lt;BR /&gt;&lt;BR /&gt;I'm glad you found the bad disk.  If the rapidly growing hold_list problem is recurrent with no apparent hardware problem, there may still be a deficiency in the STM subsystem that might require a patch.&lt;BR /&gt;&lt;BR /&gt;Best Regards,&lt;BR /&gt;&lt;BR /&gt;Dave</description>
      <pubDate>Wed, 23 Oct 2002 01:56:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831321#M88938</guid>
      <dc:creator>Dave Unverhau_1</dc:creator>
      <dc:date>2002-10-23T01:56:29Z</dc:date>
    </item>
    <item>
      <title>Re: STM</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831322#M88939</link>
      <description>The File is not growing After Oct 16. The Disk was replaced on the 16 Th. &lt;BR /&gt;We Have a Fiber Disk Array. The Faulty Disk was on the Disk array which was replaced.&lt;BR /&gt;&lt;BR /&gt;1. Stoped the diaglogd &lt;BR /&gt;2.Removed the file&lt;BR /&gt;3. touch file&lt;BR /&gt;2, restarted the diaglogd.&lt;BR /&gt;The file is zero bytes and is not growing . i will observe for 2 day.&lt;BR /&gt;&lt;BR /&gt;Thank you&lt;BR /&gt;Gopi&lt;BR /&gt;</description>
      <pubDate>Wed, 23 Oct 2002 02:00:47 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/stm/m-p/2831322#M88939</guid>
      <dc:creator>Gopinath rao_1</dc:creator>
      <dc:date>2002-10-23T02:00:47Z</dc:date>
    </item>
  </channel>
</rss>

