[GE users] Getting rid of LD_LIBRARY_PATH

Reuti reuti at staff.uni-marburg.de
Fri Oct 15 22:27:06 BST 2004


    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "ISO-8859-10" character set.  ]
    [ Some special characters may be displayed incorrectly. ]

> Actually, SGE jobs automatically get LD_LIBRARY_PATH (or whatever
> variable the OS uses) set for them, independent of sourcing the
> settings.(c)sh file.  In SGE 5.3, this happens in
> source/daemons/execd/exec_job.c in the set_sharedlib_path() function.
> So every grid job is running with the SGE library path at the
> head of LD_LIBRARY_PATH.

Oh, I see - thanks. And if you source just g03.profile as in our case, which 
sets the LD_LIBRARY_PATH (and disregard any existing one), in your script file 
and not during login (because we don't want any interactive work) it will also 
not happen.
 
> When 100s of cpus are running an SGE array job that is a shell script
> calling lots of other executables, the unnecessary ld searching
> generates a substantial network load against the NFS-shared
> $SGE_ROOT.  Enough network load, in fact, to cause lots of errors
> and rescheduling because the qmaster has trouble getting its own
> NFS traffic through to $SGE_ROOT.  We ended up solving this problem
> by running a private link between the qmaster and the NAS device
> holding $SGE_ROOT, and we instantly saw improved SGE reliability.
> We'd still like to eliminate all the needless traffic still flying
> around the network related to LD_LIBRARY_PATH. 

Maybe adjusting your script (and removing the SGE path) will also work. - Reuti

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net




More information about the gridengine-users mailing list