Bugzilla – Bug 3554
SEG not relocatable
Last modified: 2005-07-18 11:30:06
You need to log in before you can comment on or make changes to this bug.
This is a problem which was introduced in globus_4_0_branch for about one week ago. Looks like the starting globus-scheduler-event-generator from Java is not setting up the environment right to allow for relocatability. The symptom is that jobs just hang forever as no notification are coming in from SEG. I created a simple shell script around globus-scheduler-event-generator so I could get the error messages as well (using 2>&1): 2005-07-11 10:10:14,858 DEBUG monitoring.SchedulerEventGenerator [Thread-5,run:132] seg input line: /scratch/rynge/gram-test/install/libexec/globus-scheduler-event-generator.ORIG: error while loading shared libraries: libglobus_gram_protocol_gcc32.so.0: cannot open shared object file: No such file or directory What is needed is using globus-script-initializer or similar.
The problem here is that Tomcat compatibility mandated that GLOBUS_LOCATION be set for the SEG by the configuration's globusLocation value instead of relying on the inherited environment. I don't know of a way to both inherit the parent process environment while customizing specific variables. I'm changing the code back to inheriting since it's breaking Mats' installs. Hopefully there's a way to set this through Tomcat config or something.
Please do not change this back. We need to figure out another solution. In my original bug I described why relying on inherited GL env. variable is bad. I also mentioned another potential way of resolving that issue. Maybe we'll need to change how this program is started.
I'm also a little bit worried that we have other places were we do the same thing and I think it is important to fix this right and maybe mail dev-int so other components can fix their code as well. If GLOBUS_LOCATION is changed, you need to use globus-script-initializer to set the dynamic library paths correct. Depending on how the java exec is implemented, we might get away with something like setting GLOBUS_LOCATION and then: (. $G_L/libexec/globus-script-initializer; $G_L/libexec/globus-scheduler-event-generator)
Another way would be to implement a helper in Java to set up the environment, but that means yet another place to keep track of when changes to the relocatability environment is need.
After a quick phone call we decided to undo this change and live with the GLOBUS_LOCATION environment variable limitation in Tomcat for 4.0.1. But in the long term this problem must be addressed. Please make sure to update the GRAM Tomcat deployment documentation with notes on this. That GLOBUS_LOCATION must be set appropriately before Tomcat is started. Which means only one Globus version of GRAM can be deployed into the same Tomcat installation. That is, you can still deploy GRAM twice into Tomcat but it must come from the same GL installation.
Both the trunk and the globus_4_0_branch have been rolled back temporarily until we can come up with an acceptable solution.
Since this bug doesn't directly deal with the Tomcat issue, I'm closing this bug so we can eliminate it as a blocker for 4.0.1. I will submit a new bug about the Tomcat issue that mentions this bug.
Tomcat bug submitted as #3575.
