From: Dušek Martin (Martin.Dusek@pregis.cz)
Date: Sat Nov 16 2002 - 12:34:36 EST
Hi all,
many thanks to Johan Brusche, who reads the manpages - he wrote:
==========================================
The procedures you got on recycling the binary.errlog file are OUTDATED and pre V5.x.... Compaq analyze ie ca and desta will still be unhappy about the content of the binary.errlog file if you do it that way.
check the manpage for binlogd, and do the following :
# mkdir /usr/var/cluster/members/{memb}/adm/binlog.saved/
# kill -USR1 `cat /var/run/binlogd.pid`
This way the new binary.errlog will contain the recommended configuration entry at the beginning of the file.
==========================================
My additions:
In 5.1A, there is no need to "mkdir /usr/var/cluster/members/{memb}/adm/binlog.saved/", it will be created automatically.
The command "kill -USR1 `cat /var/run/binlogd.pid`"
creates (overwrites, if there is any!!!) a file:
/usr/var/cluster/members/{memb}/adm/binlog.saved/binary.errlog.saved
With best regards (and thanks, Johan),
Martin
-----Original Message-----
From: Dušek Martin
Sent: Wednesday, November 06, 2002 5:23 PM
To: tru64-unix-managers@ornl.gov
Subject: SUMMARY: desta process consumes 100% of CPU time
Hi all,
many thanks to all who answered. I summarize the most important notes:
desta should be upgraded to webes400 (I didn't do that, so I cannot confirm if it would help)
This behavior could be seen if:
===============================
binary.errlog has been corrupted
binary errlog is large (larger that 1 MB - our case, typically more than 15 MB because of many system failures)
A correct way to fix this without upgrading Java od WEBES was given by Jay Vlack:
# cd /.local../usr/var/adm
(Note: if /var is a separate filesystem from /usr, you'll cd to /.local../var/adm instead. Changing directories with .local.. is necessary to avoid writing over the binary.errlog CDSL)
# ls -l binary*
# mv binary.errlog binary.errlog.old
# /sbin/init.d/binlog stop
# /sbin/init.d/binlog start
# ls -l binary*
I had fixed that before the Jay's answer has come and did it another way (maybe not correct but it worked):
cd /var/cluster/members/{memb}/adm
cp -p binary.errlog binary.errlog_20021106
cat /dev/null >binary.errlog
gzip --best binary.errlog_20021106
/usr/opt/compaq/svctools/bin/desta_startup stop
/sbin/init.d/binlog stop
/sbin/init.d/binlog start
/usr/opt/compaq/svctools/bin/desta_startup start
Unfortunately, I got some answers telling that we can expect bad times around "the new HP" support of [not only] the WEBES tool. So goodbye Digital, hello Carly, the world has definitely changed.
With regards,
Martin Dusek
-----Original Message-----
From: Dušek Martin
Sent: Tuesday, November 05, 2002 1:50 PM
To: tru64-unix-managers@ornl.gov
Subject: desta process consumes 100% of CPU time
Hi all,
for a long time, we have had the same problem:
The desta process starts to consume nearly 100% of CPU time and doesn't stop for many hours. We have to stop and restart desta, sometimes this doesn't help.
An example:
root 2098384 99.9 0.1 238M 3.0M ?? R N Nov 01 3-09:29:21 /usr/opt/compaq/svctools/jre/bin/../bin/alpha/native_threads/java -DSvctools.Home=/usr/opt/compaq/svctools -DSwcc.Home=/var/adm com.compaq.svctools.desta.core.DESTAController
We run Tru64 5.1A PK3, but the behavior has been the same for various system levels.
We pay for the SW support, but "The new HP" claims that desta is an additional product and doesn't want to solve any problem around DESTA and Compaq Analyze.
Does anybody know the reason of this behavior?
With Best Regards,
Martin Dusek
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:59 EDT