Root Filesystem Filling Up.

[Ronnie Doggart]

Hi,

We have an RX4640 running 11.23 and the root filesystem keeps filling up. The file that is continually growing is /etc/opt/resmon/persistence/m.86234607
Can anyone tell me why this file would be growing continually, and how to stop it.

[MarkSyder]

As far as I can make out, these files appear to contain details about SCSI device errors.

Any backup failures recently?

Mark Syder (like the drink but spelt different)

[Mobeen_1]

Ronnie,
Take a look at the url below and it answers precisely what you are looking for

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=111519

let us know if you have any questions after reviewing that url

rgds
Mobeen

[Carsten Krege]

I agree with Mobeen's recommendation.

Only adding what these files are good for: These files contain the persistence database for the Event Monitoring Service (EMS) Framework. In your case this file contains the EMS monitoring requests for the EMS Hardware Monitor dm_stape that are automatically registered by the Online hardware diagnostic tools. Other m.* files contain the requests for other EMS monitors.

The persistence database is used to re-register requests after a reboot or a death of the EMS monitor. The "p_client" process goes through all the persistence files and automatically registers (=activates) the requests with the EMS Framework.

For more details read "Using the Event Monitoring Service", June 2003, on http://www.docs.hp.com/hpux/ha/#Event%20Monitoring%20Service%20and%20HA%20Monitors

Nevertheless the problem is here with OnlineDiag that is the EMS client here that continues to add monitoring requests for some reason.

Carsten

[Ronnie Doggart]

Further investigation has lead me to /etc/opts/resmon/log/api.log which has in it multiple occurences of:


-------------------Start Event--------------------
User event occurred at Wed Aug 11 12:05:12.262297 2004
Process ID: 9218 (/usr/sbin/stm/uut/bin/tools/.../dm_stape) Log Level: Error
Tool is exiting due to receipt of an unexpected signal (11).

SIGSEGV (11) signal indicates a segmentation violation.

Possible Causes/Recommended Action:

Internal Application error. Tool attempted to reference an invalid address.
Usually a NULL or bad pointer.
-------------------End Event----------------------

Any advice on what is wrong.

[Rick Garland]

You got a tape drive giving you fits. In the output that you have been receiving it will say to run a command to get more info. Do that and post here for DX.

[Ronnie Doggart]

Where does it tell me the command to run.

[MarkSyder]

Try running elm.

It should give you a list of messages that have been posted every time this error occurs. The messages will contain the script you need to run. You should be able to copy and paste it.

Mark

[Ronnie Doggart]

There are no mails.

[Dave Hutton]

Do you have anything like this in your /var/adm/syslog/syslog.log?

Jul 10 12:51:37 devon EMS [13129]: ------ EMS Event Notification ------ Value: "CRITICAL (5)" for Resource: "/system/events/core_hw/core_hw" (Threshold: >= " 3") Execute the following command to obtain event details: /opt/resmon/bin/resdata -R 860422146 -r /system/events/core_hw/core_hw -n 860422145 -a

[Ronnie Doggart]

There are no messages in the syslog like the example you gave for tape devices.