Page MenuHomePhabricator

Need help getting a uWSGI Python-Flask Labs tool to work
Closed, ResolvedPublic

Description

Hello all,

I have a set of scripts for use at the Wikipedia Signpost that have proven essential to week-to-week publication, but have found that I'm not always available to run them, or that sometimes I forget. We really need to get these tools onto Labs so that everyone can use them, not just me.

Sorry for the overwhelming detail, I wanted to lay this out in as much detail as possible.

But so far my experiences with coaxing servers into life can at this point be summed up, in a word, as "tragic"...after a previously abandoned attempt I decided to start fresh in a new signpostlab tool. I really need for more experienced eyes (read: people that know what they're doing) to take a look at this.

I have a skeleton of the web interface on my local machine: none of the scripts are plugged in yet, it's literally just one Flask file and a bunch of HTML and CSS, split up amongst a few folders. I use a conda virtual environment with Python 2.7.3 and Flask installed for development purposes: the base application is app.py, and the interface works as expected when I run it with python app.py (the Flask development server loads it to http://127.0.0.1:5000/ on your local machine). This verifies that the tool ought to work when it's imported into Labs.

I git push these files to a repository I'm storing them in on GitHub, located @https://github.com/ResidentMario/signpostlab. After using ssh to login and become signpostlab, I check this out to my src directory, ~/www/python/src, with git pull https://github.com/ResidentMario/signpostlab.git. This executes successfully. Now I restart the webservice with webservice2 uwsgi-python restart; but after execution the page 404s!

I used cp app.py _app.py to store the "actual" application and wrote the quickstarter starter application (http://flask.pocoo.org/docs/0.10/quickstart/) into app.py instead. This works! Thus currently the contents of https://tools.wmflabs.org/signpostlab/ is Hello World!.

But how can a Flask application, one that works locally, even, manage to crash a webservice? When Flask encounters an error the expected behavior is displaying a debug message for error-checking, not break its webservice!

There is something really weird going on, and I am at whit's end regarding what that is, exactly.

The contents of the most recent uwsgi.log file is:

*** Starting uWSGI 1.9.17.1-debian (64bit) on [Mon Oct 19 20:03:47 2015] ***
compiled with version: 4.8.2 on 23 March 2014 17:15:32
os: Linux-3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015
nodename: tools-webgrid-generic-1403
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /data/project/signpostlab
detected binary path: /usr/bin/uwsgi-core
your processes number limit is 63808
your process address space limit is 4000000000 bytes (3814 MB)
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address :57564 fd 3
Python version: 2.7.6 (default, Jun 22 2015, 18:01:27)  [GCC 4.8.2]
Set PythonHome to /data/project/signpostlab/www/python/venv
*** Python threads support is disabled. You can enable it with --enable-threads$
Python main interpreter initialized at 0x17da800
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 363960 bytes (355 KB) for 4 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 22 seconds on interpreter 0x17da800 pid: 30$
mounting /data/project/signpostlab/www/python/src/app.py on /signpostlab
WSGI app 1 (mountpoint='/signpostlab') ready in 25 seconds on interpreter 0x1a8$
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 30847)
spawned uWSGI worker 1 (pid: 30875, cores: 1)
spawned uWSGI worker 2 (pid: 30876, cores: 1)
spawned uWSGI worker 3 (pid: 30877, cores: 1)
spawned uWSGI worker 4 (pid: 30878, cores: 1)
[pid: 30875|app: 1|req: 1/1] 10.68.21.81 () {32 vars in 543 bytes} [Mon Oct 19 $
[pid: 30876|app: 1|req: 1/2] 10.68.21.81 () {32 vars in 543 bytes} [Mon Oct 19 $
[pid: 30878|app: 1|req: 1/3] 10.68.21.81 () {32 vars in 543 bytes} [Mon Oct 19 $

Related StackOverflow inquiry:
http://stackoverflow.com/questions/33205274/changing-the-application-file-of-interest-for-uwsgi/33223092#33223092

Event Timeline

ResMar created this task.Oct 19 2015, 8:44 PM
ResMar raised the priority of this task from to Needs Triage.
ResMar updated the task description. (Show Details)
ResMar added a project: Cloud-Services.
ResMar added a subscriber: ResMar.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 19 2015, 8:44 PM
ResMar updated the task description. (Show Details)Oct 19 2015, 8:54 PM
ResMar set Security to None.

I see:

@app.route('../wm_blog_importer', methods=['GET', 'POST'])

in the flask code. I'm not sure what the '..' represents. Have you tried making those be

@app.route('/signpostlab/wm_blog_importer', methods=['GET', 'POST'])
```?

Thanks to some wonderful sleuthing this problem has now be resolved!

It turned out to be a very simple fix, via Murphy's law: just changing the uwsgi.ini name to

wsgi=signpostlab/app.py
chasemp closed this task as Resolved.Nov 30 2015, 4:41 PM
chasemp claimed this task.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 30 2015, 4:41 PM
ResMar removed a subscriber: ResMar.Apr 15 2016, 1:45 PM