Bug 3554 - SEG not relocatable
: SEG not relocatable
Status: RESOLVED FIXED
: GRAM
wsrf scheduler interface
: 4.0.0
: PC Linux
: P3 blocker
: 4.0.1
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-07-11 12:22 by
Modified: 2005-07-18 11:30 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-07-11 12:22:52
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.
------- Comment #1 From 2005-07-11 13:20:42 -------
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.
------- Comment #2 From 2005-07-11 14:26:52 -------
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. 
------- Comment #3 From 2005-07-11 14:50:51 -------
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)

------- Comment #4 From 2005-07-11 14:53:24 -------
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.
------- Comment #5 From 2005-07-14 18:08:38 -------
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.  
------- Comment #6 From 2005-07-15 11:55:40 -------
Both the trunk and the globus_4_0_branch have been rolled back temporarily
until
we can come up with an acceptable solution.
------- Comment #7 From 2005-07-18 11:22:32 -------
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.
------- Comment #8 From 2005-07-18 11:30:06 -------
Tomcat bug submitted as #3575.