Hi Nicholas, Set `static_enabled = False` in universe_wsgi.ini and restart uWSGI, and see if that makes a difference. Thanks, --nate On Mon, Feb 2, 2015 at 11:26 AM, Nicholas Kline <nxk60@case.edu> wrote:
Hi Nate. Thanks a lot for all the help so far. So, I started uWSGI like so:
- activate virtual env - cd ~/galaxy-dist - PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste universe_wsgi.ini
Then browsed to localhost, which redirected to https://localhost/ as expected since I want all traffic to be over HTTPS, and finally returned:
502 Bad Gateway
I checked uwsgi.log and it's quite large, almost 3,000 lines. Should I post it to this list for review? I've included the last few lines below:
*** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 4083) spawned uWSGI worker 1 (pid: 4195, cores: 4) spawned uWSGI worker 2 (pid: 4199, cores: 4) spawned uWSGI worker 3 (pid: 4203, cores: 4) spawned uWSGI worker 4 (pid: 4207, cores: 4) spawned uWSGI worker 5 (pid: 4211, cores: 4) spawned uWSGI worker 6 (pid: 4215, cores: 4) spawned uWSGI worker 7 (pid: 4219, cores: 4) spawned uWSGI worker 8 (pid: 4223, cores: 4) spawned uWSGI worker 9 (pid: 4224, cores: 4) spawned uWSGI worker 10 (pid: 4225, cores: 4) *** Stats server enabled on 127.0.0.1:9191 fd: 30 *** Traceback (most recent call last): File "/home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlmap.py", line 201, in __call__ environ['SCRIPT_NAME'] += app_url KeyError: 'SCRIPT_NAME' [pid: 4219|app: 0|req: 1/1] 127.0.0.1 () {40 vars in 593 bytes} [Fri Jan 30 15:15:10 2015] GET / => generated 0 bytes in 18 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)
If you need me to post my Nginx config too, just let me know. Thanks!
On Wed, Jan 28, 2015 at 11:55 AM, Nicholas Kline <nxk60@case.edu> wrote:
Hi Nate. Thank you for the reply. So I installed uWSGI inside my Python virtual environment since that was one of the options listed in the documentation, like so:
cd ~/galaxy_env/ source bin/activate pip install uwsgi
It looks like uWSGI was successfully installed. I then exited/deactivated the virtual environment via 'deactivate'.
Next, I tried to start uWSGI:
~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste config/galaxy.ini
Calling uwsgi after deactivating the virtualenv means it'd be running from wherever it's found on $PATH, which is probably not the one you just installed into the virtualenv. But if it works, it may not matter.
... but it returned this:
realpath() of config/galaxy.ini failed: No such file or directory [core/utils.c line 3607]
So, I pointed it to universe_wsgi.ini instead, like so:
~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste universe_wsgi.ini
universe_wsgi.ini was renamed to config/galaxy.ini late last year. However, if you still have it, it's perfectly fine to leave it there and continue using it.
...and this was returned:
[uWSGI] getting INI configuration from universe_wsgi.ini
At that point, Terminal just kinda sits there and does not display any output, error messages, etc.
If uwsgi is running, this suggests it's working. If you have set up the uwsgi proxy in nginx you should be able to try to access Galaxy via the web at this point. More detail may be available in the uwsgi log file - did you set `logto` in the `[uwsgi]` section of universe_wsgi.ini?
Questions:
1. Was I correct in specifying universe_wsgi.ini ?
The location of the config file is up to you. universe_wsgi.ini in the root of the Galaxy directory was the old default.
2. Nothing is returned after "[uWSGI] getting INI configuration from universe_wsgi.ini". Is that normal?
Yes. You probably want to set `logto` as described above and start uwsgi in the background, e.g. with the `-d` command line option.
3. Should I activate the Python virtual environment first (via "source bin/activate") before executing "~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste universe_wsgi.ini" ?
Yes, I would do this.
4. Is the next step to start Galaxy, like so?
cd galaxy-dist GALAXY_RUN_ALL=1 sh run.sh --daemon
uwsgi is running your Galaxy web processes, so I would check to ensure
are working first. Once you've verified that, you can use the command above to start any job handlers you have configured.
--nate
I appreciate your help.
On Mon, Jan 26, 2015 at 5:22 PM, Nate Coraor <nate@bx.psu.edu> wrote:
Hi Nicholas,
Sorry for the somewhat misleading text in the documentation. The part about "no extra modules or recompiling" refers to nginx itself - uWSGI protocol support is built in to the core functionality of nginx. This does not mean that uWSGI itself is installed. Installing uWSGI is addressed a bit further up:
You will also need to have uWSGI installed. There are a variety of
ways
to do this. It can be installed system-wide by installing from your system's package manager (on Debian and Ubuntu systems, the uwsgi and uwsgi-plugin-python provide the necessary components), or with theeasy_install or pip commands (which will install it to the system's Python site-packages directory). Alternatively, if you are already running Galaxy from a Python virtualenv, you can use pip install uwsgi with that virtualenv's copy of pip to install to that virtualenv as your unprivileged Galaxy user.
In the case of Ubuntu sudo apt-get install uwsgi uwsgi-plugin-python should provide the necessary components.
--nate
On Mon, Jan 26, 2015 at 2:46 PM, Nicholas Kline <nxk60@case.edu> wrote:
Hello,
I am trying to setup a local production Galaxy server for our department. Our Galaxy server environment is as follows:
- Ubuntu 14.04 64-bit - 94 GB Memory - Intel Xeon - Python virtual environment - Nginx - PostgreSQL - ProFTPd
Today I tried starting the Galaxy server for the first time. I think the first step in that process is starting uWSGI, correct? To do so,
I
executed these commands:
cd ~/galaxy-dist/ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste config/galaxy.ini
However, it appears something failed. This information is returned:
The program 'uwsgi' can be found in the following packages: * uwsgi-core * uwsgi-plugin-alarm-curl * uwsgi-plugin-alarm-xmpp * uwsgi-plugin-curl-cron * uwsgi-plugin-emperor-pg * uwsgi-plugin-erlang * uwsgi-plugin-geoip * uwsgi-plugin-graylog2 * uwsgi-plugin-jvm-openjdk-6 * uwsgi-plugin-jvm-openjdk-7 * uwsgi-plugin-ldap * uwsgi-plugin-lua5.1 * uwsgi-plugin-lua5.2 * uwsgi-plugin-php * uwsgi-plugin-psgi * uwsgi-plugin-python * uwsgi-plugin-python3 * uwsgi-plugin-rack-ruby1.9.1 * uwsgi-plugin-router-access * uwsgi-plugin-sqlite3 * uwsgi-plugin-v8 * uwsgi-plugin-xslt Ask your administrator to install one of them
According to the galaxy documentation at https://wiki.galaxyproject.org/Admin/Config/Performance/Scaling , "uWSGI support is built in to nginx, so no extra modules or recompiling should be required".
Also, should '--ini-paste config/galaxy.ini' really be configured
On Wed, Jan 28, 2015 at 2:53 PM, Nate Coraor <nate@bx.psu.edu> wrote: they like
this instead: --ini-paste universe_wsgi.ini ?
Thank you ___________________________________________________________ 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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/