Hi,
I was also able to reproduce this bug on a vanilla gt4.0.8 install
running on a Slackware 12.0 system (2.6.21.5-smp) with:
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
gcc (GCC) 4.1.2
Regards,
Andre
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
--
Andre Charbonneau
Research Computing Support, IMSB
National Research Council Canada
100 Sussex Drive, Rm 2025
Ottawa, ON, Canada K1A 0R6
613 993-3129
