Thanks Nate! I did not know about sge_request - and that helps.  I played 
around with using -V and -v in sge_request some and it works similar to 
specifying -V (or -v) in my universe_wsgi.ini file.  I am new to galaxy and I 
am working on getting it instantiated locally.  Is there an advantage to 
setting my native DRMAA options in my galaxy user's  local .sge_request file 
vs. directly in the universe_wsgi.ini configuration file?  Would an advantage 
be that I can set more universal drmaa native options that I would like to 
common for all tools there (sge_request for galaxy user) vs. duplicating the in 
each per tool configurations in universe_wsgi file? 

Thanks again,

Ann

On Sep 12, 2011, at 12:50 PM, Nate Coraor wrote:

> Ann Black wrote:
>> I figured out a solution.  The sun grid engine will strip back the env of 
>> what gets passed along with the job submission.  I added a native drmaa 
>> option, -V, which caused the env vars found on the shell that submits the 
>> job to be passed along.  Therefore all the environment setup I did in my 
>> galaxy user's .bash_profile and thus configured in my local shell running 
>> galaxy now gets propagated with my job submissions.  This does not allow 
>> changes to .bash_profile to be picked up dynamically, however, since the 
>> .bash_profile is not sourced on each compute node.  IE changes made to the 
>> galaxy user's env needs to be re-sourced in the shell that runs galaxy and 
>> dispatches the jobs.
>> 
>> Thanks - hope this helps others,
> 
> Hi Ann,
> 
> For SGE, you can also use ~/.sge_request to set up the environment on
> the execution host.
> 
> --nate
> 
>> 
>> Ann
>> 
>> 
>> On Sep 12, 2011, at 10:09 AM, Ann Black wrote:
>> 
>>> Hello everyone -
>>> 
>>> I am also running into this issue trying to get galaxy integrated with our 
>>> sun grid engine.  My galaxy user's .bash_profile does not appear to get 
>>> sourced when the jobs run. I augmented the sample sam_filter.py tutorial 
>>> such that it output path and user info so I could see how the jobs were 
>>> being run:
>>> 
>>> out = open( sys.argv[2], "w" )
>>> out2 = open("/data/galaxy-dist/ann.out", "w")
>>> out2.write(socket.gethostname())
>>> out2.write("\n")
>>> out2.write(os.environ['PATH'])
>>> out2.write("\n")
>>> drmaa = os.environ.get('DRMAA_LIBRARY_PATH')
>>> if drmaa is None:
>>>  out2.write("None")
>>> else:
>>>  out2.write(os.environ.get('DRMAA_LIBRARY_PATH'))
>>> out2.write("\n")
>>> out2.write(str(os.geteuid()))
>>> out2.write("\n")
>>> out2.write(str(os.getegid()))
>>> shutil.copytree("/data/galaxy-dist/database/pbs","/data/galaxy-dist/ann")
>>> 
>>> the job is being dispatched as my galaxy user, however the my augments to 
>>> PATH and additional env vars that I have exported in our galaxy user's 
>>> .bash_profile are not present when the script runs (ie, .bash_profile is 
>>> not sourced).  When I use qsub to manually run the galaxy script that gets 
>>> generated under database/pbs, the output to ann.out reflects my PATH and 
>>> exported env vars.
>>> 
>>> Was there any other solution to this issue besides the drmaa.py script 
>>> augment?
>>> 
>>> Thanks much for your help,
>>> 
>>> Ann
>> 
>> 
>> ___________________________________________________________
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>> 
>>  http://lists.bx.psu.edu/


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

  http://lists.bx.psu.edu/

Reply via email to