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