Martin Feller wrote:
Patrick,
This sounds as if you are hitting
http://bugzilla.globus.org/globus/show_bug.cgi?id=6341
I see that I fixed that bug after 4.0.8 came out.
You can quickly check if this bug is the reason for your issue
by modifying $GLOBUS_LOCATION/libexec/globus-gram-local-proxy-tool
as suggested in the bug description.
If this is your issue, great, 4.0.9 will fix it, or you can easily
fix it by modifying globus-gram-local-proxy-tool.
If not, please report back to the list.
Would be nice if you could also give feedback if this was the issue!
Martin
Patrick Armstrong wrote:
Hi everyone,
We've been having a problem where the Globus 4.0.8 container will peg
the CPU to 99%, and we think we've tracked down how to reproduce it.
It seems to happen when you try to delegate a full credential, but
with a bad (or destroyed) epr.
We were wondering if anyone could try the following steps to confirm
the bug:
$ grid-proxy-init
$ globus-credential-delegate -h $GLOBUS_HOST $GLOBUS_HOST
$ wsrf-destroy -e $GLOBUS_HOST
$ globusrun-ws -submit -s -Jf $GLOBUS_HOST -F $GLOBUS_HOST -c
/bin/uname -a
The CPU on globus-host should now be pegged to %99 by the Globus
container process. You can get your container back to a stable state
by deleting the globus persisted directory:
[globus-host]# rm -Rf ~globus/.globus/persisted
In some cases you may need to drop and re-create your rftDatabase to
get back to a stable state.
Can anyone else reproduce this? Or is it a problem with our
configuration. We're running java 1.6 on Scientific Linux 5.1.
--patrick
