Bugzilla – Bug 3554
SEG not relocatable
Last modified: 2005-07-18 11:30:06
You need to
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
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:
error while loading shared libraries: libglobus_gram_protocol_gcc32.so.0:
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:
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
we can come up with an acceptable solution.
Since this bug doesn't directly deal with the Tomcat issue, I'm closing this
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.