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/

Ann Black wrote:

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?

Hi Ann, It probably doesn't matter whether you use .sge_request or the runner URL in the Galaxy config. The difference may simply be that .sge_request would be a little less messy. --nate

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/