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 http://pastie.org/5351347
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: http://pastie.org/5351396
(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 http://pastie.org/5351308
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
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
----- Original Message -----
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 http://pastie.org/5351347
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: http://pastie.org/5351396
(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 http://pastie.org/5351308
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 ___________________________________________________________ The Galaxy User list should be used for the discussion of Galaxy analysis and other features on the public server at usegalaxy.org. Please keep all replies on the list by using "reply all" in your mail client. For discussion of local Galaxy instances and the Galaxy source code, please use the Galaxy Development list:
http://lists.bx.psu.edu/listinfo/galaxy-dev
To manage your subscriptions to this and other Galaxy lists, please use the interface at:
On Fri, Nov 9, 2012 at 2:40 PM, Scott McManus scottmcmanus@gatech.edu wrote:
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.
Thanks Scott. I think I already have that call in there. That's why I'm so confused. See line 21 http://pastie.org/5351396
Is something not working with that call. Maybe that call affects root and not the galaxy user?
-Greg
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 run.sh --daemon --log-file /usr/local/galaxy/logs/galaxy.log" (I'm not proud of that, but it might work.)
-Scott
----- Original Message -----
On Fri, Nov 9, 2012 at 2:40 PM, Scott McManus scottmcmanus@gatech.edu wrote:
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.
Thanks Scott. I think I already have that call in there. That's why I'm so confused. See line 21 http://pastie.org/5351396
Is something not working with that call. Maybe that call affects root and not the galaxy user?
-Greg
So I ended up moving these lines:
export DRMAA_LIBRARY_PATH=/sge/current/lib/lx-amd64/libdrmaa.so 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
On Fri, Nov 9, 2012 at 3:09 PM, Scott McManus scottmcmanus@gatech.edu wrote:
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 run.sh --daemon --log-file /usr/local/galaxy/logs/galaxy.log" (I'm not proud of that, but it might work.)
-Scott
----- Original Message -----
On Fri, Nov 9, 2012 at 2:40 PM, Scott McManus scottmcmanus@gatech.edu wrote:
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.
Thanks Scott. I think I already have that call in there. That's why I'm so confused. See line 21 http://pastie.org/5351396
Is something not working with that call. Maybe that call affects root and not the galaxy user?
-Greg
galaxy-user@lists.galaxyproject.org
-
greg -
Scott McManus