By default globus-stop-container must be executed with the same credentials as the container it is running with. If the ShutdownService or the container is configured with separate private key and certificate files (usually /etc/grid-security/containercert.pem and /etc/grid-security/containerkey.pem) do the following to stop the container:

 $ grid-proxy-init -cert /etc/grid-security/containercert.pem \ -key
        /etc/grid-security/containerkey.pem \ -out containerproxy.pem $ setenv X509_USER_PROXY
        containerproxy.pem $ globus-stop-container $ unsetenv X509_USER_PROXY $ rm
        containerproxy.pem

Alternatively, the ShutdownService can be configured with a separate gridmap file to allow a set of users to stop the container. Please see WS Authentication & Authorization for details.

By default Sun 1.4.x+ JVMs are configured to use /dev/random device as an entropy source. Sometimes the machine can run out of entropy and applications (such as the container) using the /dev/random device will block until more entropy is available. One workaround for this issue is to configure the JVM to use /dev/urandom (non-blocking) device instead. For Sun JVMs a java.security.egd system property can be set to configure a different entropy source. To set the system property and pass it to globus-start-container script do the following:

 export GLOBUS_OPTIONS=-Djava.security.egd=file:/dev/urandom

or

 setenv GLOBUS_OPTIONS -Djava.security.egd=file:/dev/urandom

The same issue can also affect client programs. If you are running a client program with a GT generated script, you can set the GLOBUS_OPTIONS environment property as described above. However, if you are using a custom script or directly launching a program using the java command line, make sure to set the java.security.egd system property explicitly on the java command line. For example:

 java -classpath $CLASSPATH -Djava.security.egd=file:/dev/urandom
        my.package.FooProgram

Note: This does not apply to Windows machines.

If the following exception is visible in the Tomcat logs at startup it might cause the HTTPSValve to fail:

java.util.ConcurrentModificationException at
        java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at
        java.util.HashMap$EntryIterator.next(HashMap.java:824) at
        java.util.HashMap.putAllForCreate(HashMap.java:424) at
        java.util.HashMap.clone(HashMap.java:656) at
        mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56)

The HTTPSValve might fail with the following exception:

java.lang.NullPointerException at
        org.apache.coyote.tomcat5.CoyoteRequest.setAttribute(CoyoteRequest.java:1472) at
        org.apache.coyote.tomcat5.CoyoteRequestFacade.setAttribute(CoyoteRequestFacade.java:351) at
        org.globus.tomcat.coyote.valves.HTTPSValve.expose(HTTPSValve.java:99)

These exceptions will prevent the transport security to work properly in Tomcat.

This is a Tomcat bug. Keep restarting Tomcat until it starts without the ConcurrentModificationException or switch to a different version of Tomcat.

If you see the "java.net.SocketException: Invalid argument or cannot assign requested address" error in the container log or on the client side try setting the following property:

 $ export GLOBUS_OPTIONS="-Djava.net.preferIPv4Stack=true"

A GAR file can only be deployed or undeployed locally while the container is off. However, GAR deployment/undeployment might still sometimes fail with this error even if the container is off. This usually happens if the container has crashed or was stopped improperly preventing the container from cleaning up its state files. To resolve this problem delete any files under the $GLOBUS_LOCATION/var/state directory and try to redeploy/reundeploy the GAR file again.

In general, if you want to investigate a problem on your own please see Debugging for details on how to turn on debugging. Also, please note that most of the command line clients have a -debug option that will display more detailed error messages, including the error stack traces. Also, searching the mailing lists such as gt-user@globus.org or jwscore-user@globus.org (before posting a message) can also be very fruitful. Finally, if you think you have found a bug please report it in our Bugzilla system. Please include as much as detail about the problem as possible.