1/2 of var filled by one stm log file.

[Steve Post]

File /var/stm/logs/os/log2.raw.cur is 250 megs out of my 500 meg /var directory. I'm sure it is used by stm version A.13.00.
I'm running 11.00.
I can't find any documentation on this file. It does not sound very smart to blindly delete it. But I also can't anything on this file.

What is it? How do I trim it? Any idea where a document on stm version A.13.00 would be???
(I bet it has a new name).

[Uday_S_Ankolekar]

Hi,

You can format raw file using logtool utility.
**as root run mstm -> tools -> utility -> run, select logtool

Whenever you run stm reports these raw file get created.. If you really don't need them then delete it.

-USA..

[Steve Post]

So, you're saying I can rm log2.raw.cur?
And I don't know if I need it because I don't know what it is. But at least you got me closer. Now I can where the file is from the stm menu.
Thanks.

[Uday_S_Ankolekar]

Hi

Actually you don't need this .. next time when you run stm report this file will create again.


-USA..

[Duncan Edmonstone · Accepted solution]

Whoa there!

Before you delete this file, you must find out WHY its got so big! - This file is written to every time a significant hardware event occurrs, so it could be some component on your system is failing. And event then, you shouldn't just delete the file, you should first tell STM to start using a new log. The following will stop STM writing to your current log:

cstm << EOJ
ru logtool
sl
ok
exit
ok
exit
ok
EOJ

HTH

Duncan

[Steve Post]

I can guess at why it is so big. The file is 3-4 years old. It is so big, I could not verify some components with it around. Over the last 3-4 years I am sure we have had some crashes.
Actually about 4 months ago the system crashed because part of the memory died. Of course stm, diagnostics, syslog.log, or any other "thing" on the V-class system failed to report it. But the v-class's console computer did have a nice report about it.
I did not delete the file. I moved it to a 9 gig filesystem. I tried to analyze it, but it kept going and going and going and going.
One thing it might have reported was it was too big already. Since I moved it I can now verify the hardware.

[Steve Post]

Duncan, I relinked log2.raw.cur to its proper spot. I began to run your script one line at a time.
From there I saw the cstm provided me the information stm refused to provide.
Once I got to logtool, I could run help. In the help for THIS version of stm, it told me to run switchlogs (SL), to stop using a large log.raw.cur file. (just like you said).
When I ran it, the log2.raw.cur became log2.raw. No log3.raw.cur appeared. Probably because there are currently no hardware errors?
Well, at least I got my drive back.

thanks both or you.
PS: would have assigned points sooner but the forum was unacessable to me for a few hours.
(and ahem, pardon my fast, poor typing).

[Duncan Edmonstone]

The other advantage about cstm is that you can (if you want to!) now take a look at your old log... mstm's log viewer tends to blow up when looking at large logs, but cstm lets you write out a formatted log to a file, which you can then view with the tool of your choice.

I also like to cycle my logs regularly, to handle just this situation - the attached script is executed by cron once a month to cleanup STM

HTH

Duncan

[Duncan Edmonstone]

Oops... here's the script

HTH

Duncan