Joseph Hargitai wrote:
Nate,
could we go to the beginning of the issue:
where is the galaxy env set? I've seen a few post but I can only gather partial info.
When running locally, the environment is the environment that is in place when you start Galaxy. If you're starting via an init script, this is probably not the environment of your current shell, however. When running via SGE, the environment is the environment that is set up when the shell starts on the execution host. SGE usually starts in non-login, non-interactive mode, and this means that it reads almost nothing. In this case, the best way to set up the environment is in ~/.sge_request. See the INVOCATION section of the bash(1) man page for further clarification.
- it is NOT set from the galaxy user .bashrc or .profile
If starting from an interactive login shell, then .profile would be read by bash at startup. .bashrc is read if bash is started as an interactive non-login shell, although many installations have a .profile or .bash_profile set up to read .bashrc to negate this limatation.
- if it is indeed partially set from /etc/profile - using a Rocks cluster leaves you with many entries there to ponder
This is probably not feasible since it requires system-wide changes on every node.
- if it is using ld.so.conf.d as well - it will read /usr/lib64 entries etc...
This does not set up environment variables or Python's sys.path, only search paths for the runtime linker.
- is there a precise way to see what env is used for galaxy? The log script gives you a nice read on the python path but is there a way to see all envs? Looking at envs as the user "galaxy" does not equate what galaxy ends up using.
Sure, create a tool that runs `set` and/or `printenv`.
multiple issues on the CentOS install:
I found the setting or non-setting leading to the missing rpy module by looking at the runner log script - while it was loading python2.6.6 it was also loading the site-packages and other python parts from /usr/lib64...python2.4
Once I edited run.sh to use the correct python and correct R path and added the RHOME to the rpy dependent scripts - this problem went away seemingly only to produce an env looking issue: sh rm command not found when running rpy dependent applications. Did somehow the edit destroy the /bin and usr/bin path? Would these be set in run.sh as well?
This would indicate that $PATH was set to something like: PATH=/foo rather than: PATH=/foo:$PATH
To your question: where do you set RHOME in the env?
We'd prefer to set all path options in run.sh in case all above is true that you cannot set it in ~/.bash*
From Galaxy's standpoint, avoiding changes to run.sh is also preferable since it is version controlled (although you could make your own copy with modifications). Also, as outlined above, changes in run.sh are not propogated to the nodes when running on a cluster.
--nate
best, joe ________________________________________ From: Nate Coraor [nate@bx.psu.edu] Sent: Friday, September 02, 2011 1:40 PM To: Joseph Hargitai Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] rpy - No module named rpy CentoOs install
Joseph Hargitai wrote:
additional info:
it is possible on the same node to run manually
./gsummary.py
with the header:
#!/usr/bin/env python
import sys, re, tempfile from rpy_options import set_options set_options(RHOME='/apps1/R/2.13.1/intel/lib64/R') from rpy import *
Where else can there be an env setting to prevent this app not finding the mod from within galaxy?
Hi Joe,
If you set RHOME in the environment and then run gsummary.py without the additions, does it work?
--nate
j
________________________________ From: Joseph Hargitai Sent: Thursday, September 01, 2011 12:28 PM To: galaxy-dev@lists.bx.psu.edu Subject: rpy - No module named rpy CentoOs install
Hi,
On our Ubuntu install stat packages and all that require rpy work fine.
On our CentOs install seeing this stubborn error that I did see from previous post to be difficult to fix.
At first suspected the SGE issue - environment not transferring to compute nodes. After changing the app to run local had the same issue.
CentOs: 2.6.18-92.1.13.el5
rpy module is in:
/apps1/python/2.6.6/intel/lib/python2.6/site-packages
_rpy2122.so _rpy2131.so
version: [galaxy@compute-0-65 galaxy-dist]$ python -c "import rpy; print rpy.__version__" 1.5.1
path:
python -c 'import sys; print "\n".join( sys.path )'
/apps1/python/2.6.6/intel/lib/python2.6/site-packages/simplejson-2.0.9-py2.6-linux-x86_64.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/Sphinx-1.0.7-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/docutils-0.7-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/Jinja2-2.5.5-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/Pygments-1.4-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/nose-1.0.0-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/Traits-3.5.0-py2.6-linux-x86_64.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/nibabel-1.0.0-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/nipype-0.0.0-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/setuptools-0.6c12dev_r88846-py2.6.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/birdsuite-1.0-py2.5.egg /apps1/python/2.6.6/intel/lib/python2.6/site-packages/mpgutils-0.7-py2.5.egg /apps1/python/2.6.6/intel/lib/python26.zip /apps1/python/2.6.6/intel/lib/python2.6 /apps1/python/2.6.6/intel/lib/python2.6/plat-linux2 /apps1/python/2.6.6/intel/lib/python2.6/lib-tk /apps1/python/2.6.6/intel/lib/python2.6/lib-old /apps1/python/2.6.6/intel/lib/python2.6/lib-dynload /apps1/python/2.6.6/intel/lib/python2.6/site-packages /apps1/python/2.6.6/intel/lib/python2.6/site-packages/PIL
compiled against /R/2.13.1
env:
export PATH=.:\ /apps1/R/2.13.1/intel/bin:\ /apps1/python/2.6.6/intel/bin:\ /apps1/pipe/bowtie/0.12.7/intel:\ /apps1/pipe/bwa/0.5.9/intel:\ /apps1/samtools/0.1.13/intel/bin:\ /apps1/fastx_toolkit/0.0.13/intel/bin:\ /apps1/maq/maq-0.7.1:\ /apps1/maq/maq-0.7.1/scripts:\ /apps1/bfast/bfast-0.6.5a/butil:\ /apps1/bfast/bfast-0.6.5a/scripts:\ /apps1/abyss/1.2.7/intel/bin:\ /apps1/velvet/velvet_1.0.12:\ /apps1/pipe/tophat/1.3.0/intel/bin:\ /apps1/pipe/cufflinks/1.0.3/intel/bin:\ /apps1/blast/2.2.25/gnu/bin:\ /apps1/blast+/2.2.5/gnu/bin:\ /apps1/sputnik/intel/bin:\ /apps1/taxonomy/intel/bin:\ /apps1/add_scores/add_scores:\ /apps1/emboss/6.4.0/intel/bin:\ /apps1/hyphy/hyphy/HYPHY:\ /apps1/lastz/1.02.00:\ /apps1/perm/0.3.6/intel/bin:\ /apps1/beam2/intel/bin:\ /apps1/pass2/intel/bin:\ /apps1/plink/1.07/intel/bin:\ /apps1/fbat/2.0.3/bin:\ /apps1/eigensoft/3.0/intel/bin:\ /apps1/mosaik/Mosaik-1.1.0021-Linux-x64/bin:\ /apps1/freebayes/freebayes.git/bin:\ $PATH
export LD_LIBRARY_PATH=.:\ /apps1/python/2.6.6/intel/lib:\ /apps1/libgtextutils/0.6/intel/lib:\ /apps1/emboss/6.4.0/intel/lib:\ /apps1/intel/lib/intel64:\ /apps1/intel/mkl/lib/em64t:\ /apps1/tcltk/8.5.9/intel/lib:\ /apps1/zlib/1.2.5/intel/lib:\ /apps1/graphviz/2.26.3/intel/lib:\ /apps1/python/2.6.6/intel/lib/python2.6/site-packages/simtk/chem/openmm/OpenMM:\ /apps1/python/2.6.6/intel/lib/python2.6/site-packages:\ /apps1/libpng/1.5.0/intel/lib:\ /apps1/R/2.13.1/intel/lib64/R/lib:\ $LD_LIBRARY_PATH
export PKG_CONFIG_PATH=.:\ /apps1/R/2.13.1/intel/lib64/pkgconfig:\ /apps1/libgtextutils/0.6/intel/lib/pkgconfig:\ /apps1/sparsehash/1.11/intel/lib/pkgconfig:\ $PKG_CONFIG_PATH
export CLASSPATH=.:\ /apps1/gatk/gatk-git/dist:\ /apps1/gatk/gatk-git/lib:\ /apps1/srma/srma-0.1.13:\ /apps1/haploview/4.2:\ /apps1/picard/picard-tools-1.50:\ /apps1/fastqc/fastqc-0.9.5:\ $CLASSPATH
best, joe
___________________________________________________________ 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: