topic Re: /var 95% full again /var/stm/logs/os in Operating System - HP-UX

/var 95% full again /var/stm/logs/os

Franky Leeuwerck — Mon, 06 May 2002 12:03:16 GMT

Hi,

Just recently, 10 days ago, we cleaned up the /var/stm/logs/os directory containing a lot of 'logxxx.raw' files.
In the meantime this directory has been filled up with 130 MB's of these log files ?

I know these files can be cleaned up manually but my concern is :
- can I avoid or minimize this growing of log files
- is there something else going wrong on the system ?

Thanks in advance.

Franky

Re: /var 95% full again /var/stm/logs/os

Justo Exposito — Mon, 06 May 2002 12:54:31 GMT

Hi,

This sounds like a stm problem, do you have the latest patches for STM installed?

I had a problem like this in the past, and I solved by patching STM.

Regards,

Justo.

Re: /var 95% full again /var/stm/logs/os

Helen French — Mon, 06 May 2002 12:59:01 GMT

Hi Franky:

try these:

1) Patch the system to the latest one.
2) Check the stm logs and find out the resource which the stm keep complaining. Rectify it if something wrong.
3) Check all hardware with stm.
4) Check the syslog.log too for any errors.

HTH,
Shiju

Re: /var 95% full again /var/stm/logs/os

S.K. Chan — Mon, 06 May 2002 13:05:23 GMT

If you have newer version of STM (mar 2001 release) you can quickly run these and post the output here .. to determine what kind of errors are getting logged

# cd /var/stm/logs/os
# cclogview ccbootlog | more
# cclogview ccerrlog | more

OR just get into STM to view it ..

# cstm
cstm> ru logtool
Log Utility> ce

Post the output here.

Re: /var 95% full again /var/stm/logs/os

MANOJ SRIVASTAVA — Mon, 06 May 2002 13:15:46 GMT

Hi Frank

Do you have disk array problem where in there a lot of logs which ahve devopled bcoz of a mirroed disk which apparently doesnt make the system down but gives you lots of logs , this can also be caused by a defective disk or disk with lots of soft errors may be a look at the logs will show you more so untill you dont fix the cause stm logs will grow.

Manoj Srivastava

Re: /var 95% full again /var/stm/logs/os

Franky Leeuwerck — Mon, 06 May 2002 13:17:53 GMT

This is what I get running cstm> ru logtool:

host: cstm
Running Command File (/usr/sbin/stm/ui/config/.stmrc).
-- Information --
Support Tools Manager
Version A.22.00

Logtool Utility>ce
-- Chassis Log INFORMATION --
A chassis Error log file does not exist in
/var/stm/logs/os/.
See Logtool Activity Log for more information.
The View Chassis Error Log function failed. Check the Tool Activity Log for additional information.
Logtool Utility>

Re: /var 95% full again /var/stm/logs/os

S.K. Chan — Mon, 06 May 2002 13:36:57 GMT

Ohh, you probably got all the log files deleted already in /var/stm/logs/os ? Anyway take a look at this dir and see what files are in there. Also try ..

Logtool Utility> cb

and

Logtool Utility> vda

First one is viewing boot chassis log, 2nd on is memory log (from file "memlog").

Re: /var 95% full again /var/stm/logs/os

Franky Leeuwerck — Mon, 06 May 2002 13:50:27 GMT

Thanks all for your answers.

The /var/stm/logs/os dir contains only logxxx.raw files.

Viewing the current log in stm with RawLog command causes the directory to grow further. I interrupted it and contact local hp support for checking on the system and the stm patches.

Thanks a lot

Franky

Re: /var 95% full again /var/stm/logs/os

twang — Tue, 24 Jun 2003 22:24:21 GMT

# cstm
cstm> ru logtool
Logtool Utility> cb
Logtool Utility> vda
(viewing boot chassis log & memory log)
Log Utility> cl
(clean the memory log)

Re: /var 95% full again /var/stm/logs/os

Michael Steele_2 — Wed, 25 Jun 2003 00:18:44 GMT

Better see what's making all the hub bub before you delete everything:

STM > TOOLS > UTILITY > RUN > LOGTOOL > FILE > VIEW > RAW SUMMARY.

Note the first and last dates of transactions and calculate the difference. If the difference is short, like 4 hours, then this is important to note. Now read down the report of hardware addresses and observe the integer numbers in parenthesis. Anything over 150 in this 4 hour period should be called into HP for replacement.