Instead of upgrading everything on my server, I'm just starting from scratch. From Ubuntu 16.04 to Ubuntu 19.04 and I also upgraded everything else in sight. One of them was uwsgi
. I copied various user config files but for uwsgi
things didn't very well. On the old server I had uwsgi
version 2.0.12-debian
and on the new one 2.0.18-debian
. The uWSGI changelog is pretty hard to read but I sure don't see any mention of this.
You see, on SongSearch I have it so that Nginx talks to Django via a uWSGI socket. But the NodeJS server talks to Django via 127.0.0.1:PORT
. So I need my uWSGI config to start both. Here was the old config:
[uwsgi] plugins = python35 virtualenv = /var/lib/django/songsearch/venv pythonpath = /var/lib/django/songsearch user = django uid = django master = true processes = 3 enable-threads = true touch-reload = /var/lib/django/songsearch/uwsgi-reload.touch http = 127.0.0.1:9090 module = songsearch.wsgi:application env = LANG=en_US.utf8 env = LC_ALL=en_US.UTF-8 env = LC_LANG=en_US.UTF-8
(The only difference on the new server was the python37
plugin instead)
I start it and everything looks fine. No errors in the log files. And netstat
looks like this:
# netstat -ntpl | grep 9090 tcp 0 0 127.0.0.1:9090 0.0.0.0:* LISTEN 1855/uwsgi
But every time I try to curl localhost:9090
I kept getting curl: (52) Empty reply from server
. Nothing in the log files! It seemed no matter what I tried I just couldn't talk to it over HTTP. No, I'm not a sysadmin. I'm just a hobbyist trying to stand up my little server with the tools and limited techniques I know but I was stumped.
The solution
After endless Googling for a resolution and trying all sorts of uwsgi
commands directly, I somehow stumbled on the solution.
[uwsgi]
plugins = python35
virtualenv = /var/lib/django/songsearch/venv
pythonpath = /var/lib/django/songsearch
user = django
uid = django
master = true
processes = 3
enable-threads = true
touch-reload = /var/lib/django/songsearch/uwsgi-reload.touch
-http = 127.0.0.1:9090
+http-socket = 127.0.0.1:9090
module = songsearch.wsgi:application
env = LANG=en_US.utf8
env = LC_ALL=en_US.UTF-8
env = LC_LANG=en_US.UTF-8
With this one subtle change, I can now curl localhost:9090
and I still have the /var/run/uwsgi/app/songsearch/socket
socket. So, yay!
I'm blogging about this in case someone else ever gets stuck in the same nasty surprise as me.
Also, I have to admit, I was fuming with rage from this frustration. It's really inspired me to revive the quest for an alternative to uwsgi
because I'm not sure it's that great anymore. There are new alternatives such as gunicorn
, gunicorn
with Meinheld
, bjoern
etc.
Comments
http and http-socket are different options: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
Something changed at the debian package level, not uWSGI (that being a commercial project did not change options in almost 10 years, with all the problems that this kind of approach brings)
As I had this same problem with the Debian package, I would like to note that the problem is solved by simply adding "http" to the list of plugins configured. No need to add a further debian package.
This is implied by the answer above, but not clear enough for me.