Question: Trouble Installing Galaxy On Cluster
gravatar for mailing list
6.1 years ago by
mailing list840
mailing list840 wrote:
So here is what I've installed so far. (/usr/local/galaxy) is a directory that all nodes in the cluster can see. And the web server machine can also see it.) $ls -l /usr/local/galaxy drwxrwxr-- 20 galaxy scicomp 2206 Nov 8 15:53 galaxy-dist -rwxrwxr-x 1 galaxy scicomp 1882 Nov 8 15:34 galaxy.fedora-init drwxr-xr-x 5 galaxy scicomp 67 Nov 8 10:08 galaxy_python -rw-r--r-- 1 galaxy scicomp 80 Nov 8 15:32 job_environment_setup_file drwxrwxr-- 2 galaxy scicomp 28 Nov 8 15:43 logs Here are are the changes I made to galaxy-dist/universe_wsgi.ini Here is what I put in my job_environment_setup_file: export TEMP=/scratch/galaxy source /usr/local/galaxy/galaxy_python/bin/activate The galaxy_python directory contains my virtual env based off of Python 2.7. Finally here are the contents of my galaxy.fedora-init file: (Note: I created a sym link in /etc/init.d/ to /usr/local/galaxy/galaxy.fedora-init Then ran chkconfig --add galaxy.fedora-init So I can use sudo /sbin/service galaxy.fedora-init start/stop) Here are the results from running: $sudo /sbin/service galaxy.fedora-init start So my first question is why does it appear to be using Python 2.6? Is it not using my virtual env? Am I using virtual env incorrectly? Thanks, Greg
galaxy • 1.1k views
ADD COMMENTlink modified 6.1 years ago by Scott McManus130 • written 6.1 years ago by mailing list840
gravatar for Scott McManus
6.1 years ago by
Scott McManus130
Scott McManus130 wrote:
I'll take a couple of stabs at this. First, make sure that /scratch/galaxy exists. There's an error at the bottom of your pastie that seems to indicate it's not there. Second, you're right about virtualenv not being used. It is likely that root is being used, which means that all of the virtualenv stuff for the galaxy user won't be available. I haven't tried this, but you could try modifying your galaxy.fedora-init to contain a call to virtualenv - that way you switch into the proper sandbox when you startup. -Scott
ADD COMMENTlink written 6.1 years ago by Scott McManus130
Thanks Scott. I think I already have that call in there. That's why I'm so confused. See line 21 Is something not working with that call. Maybe that call affects root and not the galaxy user? -Greg
ADD REPLYlink written 6.1 years ago by mailing list840
Whoops. I missed that (obviously). When you use "su", you preserve the existing environment. When you use "su -", you use the root environment and discard the calling user's environment. So I'm guessing that what's happening in the "start" command is that the "su -" is dumping the previous env. You could try prepending the virtualenv to the command that is executed as part of "-c": cmd="source /usr/local/galaxy/galaxy_python/bin/activate; cd $RUN_IN && sh --daemon --log-file /usr/local/galaxy/logs/galaxy.log" (I'm not proud of that, but it might work.) -Scott
ADD REPLYlink written 6.1 years ago by Scott McManus130
So I ended up moving these lines: export DRMAA_LIBRARY_PATH=/sge/current/lib/lx-amd64/ export TEMP=/scratch/galaxy source /usr/local/galaxy/galaxy_python/bin/activate from galaxy.fedora-init to the galaxy user's .bashrc file. (/home/galaxy/.bashrc) It seems to be working, I see the virtual env on the python path in the log file so I think it's working. Now I'm on to a database connection problem. Thanks for the help! -Greg
ADD REPLYlink written 6.0 years ago by mailing list840
Please log in to add an answer.


Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 176 users visited in the last hour