STM

[Gopinath rao_1]

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.

How can i stop/disable STM ?
Is it OK to Stop STM ?
Can i Delete this file ?

Thank you
Gopi

[Michael Tully]

Hi,

I would not be disabling the diagnostic daemon. This daemon also sends messages to 'dmesg' and /var/adm/syslog/syslog.log.

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.

HTH
Michael

[Bill Hassell]

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.

[Gopinath rao_1]

Yes we had a bad disk which was replaced and the problem is fixed now.
how can i read the contents of the /daiglogd_hold_list.

I have not used STM ?
can make this a zero byte file for now.

Thank you
Gopi

[Dave Unverhau_1]

Gopi,

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?

It might help to attach the output of an 'swlist -l product' command.

You might try the following to see if things normalize:

/sbin/init.d/diagnostic stop
rm /var/stm/data/diaglogd_hold_list
touch /var/stm/data/diaglogd_hold_list
/sbin/init.d/diagnostic start

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.)


Regards,

Dave

[Dave Unverhau_1]

Gopi,

(I was formulating my reply and didn't see the previous responses before transmitting mine.)

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.

Best Regards,

Dave

[Gopinath rao_1]

The File is not growing After Oct 16. The Disk was replaced on the 16 Th.
We Have a Fiber Disk Array. The Faulty Disk was on the Disk array which was replaced.

1. Stoped the diaglogd
2.Removed the file
3. touch file
2, restarted the diaglogd.
The file is zero bytes and is not growing . i will observe for 2 day.

Thank you
Gopi