The documentation for writing plugins is quite barebone, i think it can be improved.
https://github.com/unbit/uwsgi-docs/blob/master/tutorials/WritingPlugins.rst

I use django , uwsgi and nginx server a web site. but every time I want to public some new version. it always turn out to be error.

I refrest the code, and restart the uwsgi with
kill -1 cat uwsgi.pid. then it turn out to be 502 or 504.

all I have to do is
ps aux | grep uwsgi
sudo kill -9
and restart the uwsgi, then it works.

that is really headache. And I found a problem, kill -9 cat uwsgi.pi only can a pid, the others remain alive and I have to kill -9 with all the pid and restart it.

At least two wrong configuration reported in the last few weeks

i may be wrong but the tutorial is not working for me https://github.com/unbit/uwsgi-docs/blob/master/tutorials/Django_and_nginx.rst

its not working when i tried to run
uwsgi --http :8000 --wsgi-file test.py

uwsgi: unrecognized option '--wsgi-file'

i ran the command as root
let me know what i did wrong

In https://github.com/unbit/uwsgi-docs/blob/master/tutorials/Django_and_nginx.rst, paragraph "Make uWSGI startup when the system boots", it is suggested to add the line
"/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data"
to /etc/rc.local. However this command never returns and every init script coming after /etc/init.d/rc.local is never executed. I suggest to add
"/usr/local/bin/uwsgi --emperor /etc/uwsgi/vassals --uid www-data --gid www-data &"
instead.

use base should be use-pattern
http://uwsgi-docs.readthedocs.org/en/latest/Fastrouter.html#way-2-fastrouter-use-pattern

I have a django-rest app that has most of their urls under /api/ path. When deploying with gunicorn I was using mod_rewrite + proxy, and this simple rule worked:

RewriteRule /api(/(.*))? http://localhost:8000/api$1 [P,L]

Now I tried to migrate to uwsgi and had problems with setting proper paths. With this line:

ProxyPass /api uwsgi://127.0.0.1:8000/api

I've got 404, as when getting i.e. /api/docs/ it was striping "/api" part and wsgi/django got request to /docs. Actually I've noticed that it doesn't matter what I add in path of the second argument of ProxyPass, it was always striping "/api" from original part.

I tried also different --mount options to uwsgi, but to no avail. Finally I started to play with --route options, and found that this options solves problem:

--route-uri '(.*) rewrite-last:$1'

I find it a bit strange as it seems to be no-op, but it works - and when I remove it, it fails with 404 again. So maybe I didn't understand something and I'm doing it wrong - but maybe it's some bug? Please clarify.

Docs frequently mention "SystemD" and link to the systemd homepage where it says:

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple.

Download section has only info about 1.4 and 1.2 relases, we should add 1.9 there, but the question is how it should be named since stable is taken for 1.4.

I would use this labels:

unstable - git repo
stable - 1.9
LTS - 1.4
previous LTS - 1.2

And maybe we could add there description of release policy, what does LTS means, what gets backported and such.

Hi,

I hope this is a feature request for something which is currently not in uwsgi and is useful for others too.
My use case is the following:
I have web clients, which talk to my app running in uwsgi (python). I have a backend connection and a connection state for each clients, these are costly to build up and tear down, so it would be nice if this would only happen once for each client, no matter how often they issue web requests.
For this to work, ideally two things must happen:

• route the same client to the same uwsgi instance (or better: machine)
• allow the app in uwsgi to share an FD cache of its connections and related connection state between multiple processes (or maybe multiple uwsgi instances)

Of course this could be done outside uwsgi, but it would be nicer to have it inside with the same API for the languages which support FD passing on unix domain sockets.

I guess this could look something like this: an uwsgi server, listening on a UDS could be the FD cache, which would store the FDs with arbitrary keys.
All uwsgi servers connecting to this cache server on the same machine could get and return FDs to this cache by key.
The cache server invalidates/removes entries if a connection closes, also a timeout could be set, so if there is no usage on that, it would expire (and close) automatically.
It would be the most useful (at least for me :) with gevent ioloop.

Thanks for considering.

The documentation for using the Mono plugin is sparse and uninformative. I've followed the example exactly as writen here: https://github.com/unbit/uwsgi-docs/blob/master/Mono.rst
I tried with same packages listed and I can't seem to get it working at all. Can you please give a working example using up-to-date packages?

EDIT: I just realized, I opened this for the wrong project, please feel free to remove it.

Hey,

I have a Cherokee, uwsgi, django stack and when I kill (sigkill) all the uwsgi worker processes without killing the master one they stay defunct, despite the fact that I have vacuum and reaper turned on. Not a likely scenario, I know but is there a way to slay and respawn them?

This is my command line for uwsgi in cherokee:
/usr/bin/uwsgi --reaper --vacuum -p 24 --plugin python --ini /path/to/my/uwsgi.conf

[uwsgi]
socket = 127.0.0.1:49673
chdir = /path/to/my/djangoapp
pythonpath = ..
env = DJANGO_SETTINGS_MODULE=djangoapp.settings
module = django.core.handlers.wsgi:WSGIHandler()

To reproduce, simply run:

UWSGI_VERSION=2.0.10 ./uwsgi

Trying the tutorial, running

uwsgi --http :8000 --wsgi-file test.py

I get

uwsgi: unrecognized option '--wsgi-file'

I get it to work if I add --plugin python, so it's

uwsgi --http-socket :8000 --plugin python --wsgi-file app.py

Not sure this is the right place to submit this.

Here http://uwsgi-docs.readthedocs.org/en/latest/Options.html#alarms "See also" does not have a link to "Alarms". I've seen similar issues in other places too.

Here https://github.com/unbit/uwsgi-docs/blob/master/Options.rst#daemonize link to "Logging" is broken. The same in daemonize2 option. I noticed it here: http://uwsgi-docs.readthedocs.org/en/latest/Options.html#daemonize - no link at all.

Maybe there is a checker that checks for broken links and rst validity?

Code-block with .ini file example[1] is not properly rendered and example is not visible both at github[2] and readthedocs[3].

[1] https://github.com/unbit/uwsgi-docs/blame/master/Options.rst#L140
[2] https://github.com/unbit/uwsgi-docs/blob/master/Options.rst#map-socket
[3] http://uwsgi-docs.readthedocs.org/en/latest/Options.html#map-socket

Hi, this is probably not a bug. But I think some people might be facing the same issue. I was trying to build uWSGI with asyncio support following the uWSGI documentation. I'm using OS X 10.10.1 "Yosemite" with Virtualenv so I presume I have to amend the path to the include directory, which in my case is the following /Users/ander/Virtualenvs/project23/include/python3.4m. So with my virtualenv activated I tried the command:

CFLAGS="-I/Users/ander/Virtualenvs/project23/include/python3.4m" UWSGI_PROFILE="asyncio" pip3 install uwsgi

However I'm getting this error:

core/json.c:125:10: fatal error: 'yajl/yajl_tree.h' file not found

#include <yajl/yajl_tree.h>
         ^
1 error generated.

Did you run into any of these issues when trying to install Asyncio compatibility for uWSGI?

As the caching subsystem is now the core of different areas, and not only of web caching, i suggest to create a new Caching.rst page describing the cache at the low level, and move the current Caching.rst to WebCaching.rst

Sphinx uses some additional directives to generate docs. Those directives are mis-interpreted by standard rest parsers (like the one used by github or the upcoming efesto app).

The main problem is maintaining document references, for Example:

github/efesto will search for HTTP.rst
sphinx will search for HTTP.html

It's unclear if the new mod_proxy_uwsgi provides any way to set the modifier for the requests, or if it is simply undocumented in the page.

I can't figure out what's the designated way for specifying the number of routes, since http://uwsgi-docs.readthedocs.org/en/latest/Fastrouter.html?highlight=fastrouter still refers to fastrouter-subscription-slot, which apparently has been deprecated.

From 1.2.4 changelog:

* added --wsgi-env-behaviour for choosing the WSGI environ
allocator/destroyer policy

There are two policies available:

'cheat' (the default one) it preallocates the env dictionary on uWSGI
startup and clear it after each request

'holy' it creates and destroyes the environ dictionary at each request

It's a small thing, but noticeable when you don't know already... wait_fd_read docs simply state you can pass a "timeout" but it doesn't specify what the unit of time is. After looking at some examples I figured out it was seconds. However, it's also not clear if I can specify fractions of a second with a float or not.

Obviously the same issue exists with wait_fd_write.

I followed the documentation as instructed here: https://github.com/unbit/uwsgi-docs/blob/master/Systemd.rst#adding-the-emperor-to-systemd

Particularly, I created a emperor.uwsgi.service file with the following contents:

[Unit]
Description=uWSGI Emperor
After=syslog.target

[Service]
ExecStart=/root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini
RuntimeDirectory=uwsgi # Requires systemd version 211 or newer
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

Notice the RuntimeDirectory setting has an inline comment. Well, it doesn't appear that this is actually treated as an inline comment:

:~ $ ls -l /run/
total 28
drwxr-xr-x 2 root  root     40 Feb  7 00:49 #
drwxr-xr-x 2 root  root     40 Feb  7 00:49 211
drwxr-xr-x 2 avahi avahi    80 Feb  6 21:17 avahi-daemon
-rw-r--r-- 1 root  root      4 Feb  6 21:17 crond.pid
---------- 1 root  root      0 Feb  6 21:17 crond.reboot
drwxr-xr-x 2 root  root     60 Feb  6 21:17 dbus
lrwxrwxrwx 1 root  root     25 Feb  6 21:17 initctl -> /run/systemd/initctl/fifo
drwxrwxrwt 4 root  root    100 Feb  6 21:17 lock
drwxr-xr-x 3 root  root     60 Feb  6 21:17 log
drwxr-xr-x 2 root  root     60 Feb  6 21:17 mount
drwxr-xr-x 2 mysql root     80 Feb  6 21:19 mysqld
drwxr-xr-x 2 root  netdev   80 Feb  6 21:17 network
drwxr-xr-x 2 root  root     40 Feb  7 00:49 newer
-rw-r--r-- 1 root  root      5 Feb  6 21:22 nginx.pid
-rw-r--r-- 1 root  root      3 Feb  6 21:17 ntpd.pid
drwxr-xr-x 2 root  root     40 Feb  7 00:49 or
drwxrwsr-x 2 redis redis    60 Feb  6 21:17 redis
drwxr-xr-x 2 root  root     40 Feb  7 00:49 Requires
-rw-r--r-- 1 root  root      4 Feb  6 21:17 rsyslogd.pid
drwxrwxr-x 3 root  utmp     60 Feb  7 00:13 screen
drwxr-xr-x 2 root  root     40 Feb  6 21:17 sendsigs.omit.d
lrwxrwxrwx 1 root  root      8 Feb  6 21:17 shm -> /dev/shm
drwxr-xr-x 2 root  root     40 Feb  6 21:17 sshd
-rw-r--r-- 1 root  root      4 Feb  6 21:17 sshd.pid
drwxr-xr-x 6 root  root    120 Feb  7 00:50 systemd
-rw-r--r-- 1 root  root      4 Feb  6 21:17 thd.pid
srwxr-xr-x 1 root  root      0 Feb  6 21:17 thd.socket
drwxr-xr-x 2 root  root     60 Dec 31  1969 tmpfiles.d
drwxr-xr-x 7 root  root    160 Feb  6 21:17 udev
drwxr-xr-x 2 root  root     40 Feb  6 21:17 user
-rw-rw-r-- 1 root  utmp   2688 Feb  7 00:44 utmp
drwxr-xr-x 2 root  root     40 Feb  7 00:49 uwsgi
drwxr-xr-x 2 root  root     40 Feb  7 00:49 version

Notice that there are a few odd directories: #, Requires, 211, or, newer.

See:
unbit/uwsgi#885

I'm a newcomer here, but it's my impression that --fs-reload (a la fsmon) has arrived since the Art of Graceful Reloading document was written.

There's strikingly little (no?) documentation of fs-reload, but it seems to perform well for graceful reloads? Perhaps it should be added to this document as a super-simple option? If it is not, in fact, a graceful reloader, perhaps that could be mentioned in that doc as well?

uWsgi is randomly spiking to 100% for a few seconds on a nginx/Django/Python project. Has anyone seen this issue before? Another developer is saying that its because dJango doesn't know how to serve dynamic generated JavaScript files I don't believe that's the case at all. How would one go about debugging this issue?

I'm trying to monitor the uwsgi status, which field explains the uwsgi process queue is not empty, and what's the difference between 'signal queue' and 'listen queue'

hi,

uWSGI can be used with the C programming language?

Sample C

#include <stdio.h>

int main ()
{
     printf ("Hello World");
}

Do I have to transfer the output to the web with uwsgi?.

I'm about 50% sure this is a Django / Django Haystack bug...

The error happens when running on:

• NGINX 1.4.4
• uWSGI 2.0
• PostgreSQL 9.3
• elasticsearch 0.90.9
• Django 1.4.4

When running several very expensive searches against elasticsearch I get this error:

and the whole worker is toast.

Here's my python requirements file:

Django==1.4.10
PIL==1.1.7
Whoosh==2.4.0
django-grappelli==2.4.8
django-haystack==2.0.0
django-mailchimp==0.1.30
django-registration==0.7
django-singletons==0.1.6
django-tagging==0.3.1
django-tinymce==1.5.2
psycopg2==2.4.5
pyelasticsearch==0.6.1
python-cjson==1.0.5
requests==2.1.0
simplejson==3.3.2
six==1.5.2
sorl-thumbnail==11.12
wsgiref==0.1.2

Here's my global defaults config:

[uwsgi]
autoload = true
master = true
cheaper-algo = spare
cheaper = 2
cheaper-initial = 5
workers = 30
cheaper-step = 1
idle = 300
no-orphans = true
pidfile = /run/uwsgi/%(deb-confnamespace)/%(deb-confname)/pid
socket = /run/uwsgi/%(deb-confnamespace)/%(deb-confname)/socket
stats = /tmp/%(deb-confname).uwsgi.stats
chmod-socket = 660
log-date = true
uid = www-data
gid = www-data
vacuum = true
max-requests = 5000
harakiri = 20

Here's my app's config:

[uwsgi]
max-requests = 500
uid = xxxxxxxxxx
workers = 5
chdir =  /var/www/xxxxxx
module = xxxxx.wsgi:application
home = /var/www/xxxxxxx
daemonize=/var/log/uwsgi/%n.log
touch-reload=../.touch-reload

The gevent plugin complains "!!! Running gevent without threads IS NOT recommended, enable them with --enable-threads !!!" (https://github.com/unbit/uwsgi/blob/7598666768578e30f03d66c43aa952c8fd8ba7cd/plugins/gevent/gevent.c#L315) when running with thread = false.

But the docs say "uWSGI multithread mode (threads option) will not work with Gevent. Running Python threads in your apps is supported." (https://github.com/unbit/uwsgi-docs/blob/master/Gevent.rst#L18)

Options.rst is supposed to be by generate_options.pl, e.g. perl generate_options.pl ~/src/uwsgi > Options.rst. Unfortunately it looks outdated and it has been patched manually. Additional help should be added to optdefs.pl instead.

There is no documentation around the safe-pidfile option except this pull request but it looks like a better alternative to the standard pidfile option and I think it should be recommended for all new projects.

I can submit a pull request updating the docs if you are OK with this.

It would be useful for newbies to find a list external tools that helps managing their uwsgi instances.
The ones that comes to mind:
https://github.com/xrmx/uwsgitop
https://github.com/piglei/uwsgi-sloth/
https://github.com/defcube/uwsgiFouine
https://github.com/goir/uwsgicachetop
https://github.com/20tab/uwsgi-local-dns-resolver
https://github.com/Yelp/uwsgi_metrics

Hi all,

I've been using uWSGI on FreeBSD 9 to serve a Django site that I've been working on, with a Nginx frontend. It generally works very well.

Except when it doesn't. Sometimes I'll get a hung uWSGI process. These are probably my fault (python blocking and hanging up) however, I expect I should be able to kill -9 these processes and they should quit.

Maybe I'm doing it wrong.

And it's really problematic because when I finally do a last ditch reboot... the reboot hangs on... right, killing the uWSGI process. So it ends up having to be a hard reset.

I really can't go to production like this. Can someone help?

Please document what uwsgi does for workers and processes by default if values are not passed by user

I am using nginx+django+uwsgi to deploy my app.
Now I get a strange error with https issue
My django version is 1.6, uwsgi version is 2.0.4 and python version is 2.7.3
I can visit https url by django shell:
In [1]: import urllib2
In [2]: response=urllib2.urlopen("https://www.baidu.com")
In [3]: data=resposne.read()
In [5]: print data

graceful reloads don't seem to be working consistently for me. I tried running uwsgi with the fs-reload option, which seemed to work for a while. Then I tried the following code in another process:

for process in psutil.get_process_list():
  if process.name() in ['python', 'uwsgi']:
    os.kill(process.pid, signal.SIGHUP)

Unfortunately, only one or two of my 4 threads seem to have reloaded.

There were no ongoing requests at time of requested reload. There were many requests afterwards. Only some of them returned the updated response.

always found error with:

  - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 296]
  IOError: write error

what's happened ?

uwsgi.websocket_recv() sometimes returns incomplete messages. A subsequent call of uwsgi.websocket_recv() will receive the rest (or the next part).

According to the uwsgi docs uwsgi.websocket_recv() is supposed to return messages (i.e. not parts of messages) and the websocket RFC sounds like any ws-implementation is supposed to assemble messages before signalling the user that a new message has arrived.

The bug is really hard to reproduce, most of the time I receive complete messages. Sending data over a slow connection (e.g. 3G network) helps alot.

I'm using uwsgi 2.0.7.

At least muleloop is not documented

Hi,

So you're completely missing the new gevent documentation. Also your async documentation might be misleading. I took it to mean that it would swap to another request while you have no greenlets running which isn't the case. It actually swaps to another request when you yield out of the current request.

In
https://uwsgi.readthedocs.org/en/latest/tutorials/Django_and_nginx.html
Do a search for
uwsgi --http :8000 --module mysite.wsgi
Thats wrong, you get a mesage from wsgi that says that app cannot be found the command that works is
uwsgi --http :8000 --wsgi-file mysite.py

Now when request headers size is more than possible uwsgi just closes connection (TCP RST) and there is nothing interesting in logs that indicate about headers size. I think it will be great to write some info in log

The django and and nginx tutorial does not explain how to make a socket for nginx to talk to django, it is just assumed that the .sock file already exists.

I just tried today - compiled fine, startup fine. However when I run (a django app) and make a request via browser, I got internal server error.

Searching the log of uwsgi I found this:

From callback <function uwsgi_pypy_wsgi_handler at 0xb406cf10>:
Traceback (most recent call last):
File "c callback", line 235, in uwsgi_pypy_wsgi_handler
File "/opt/pypy-2.0.2/lib_pypy/cffi/api.py", line 226, in string
return self._backend.string(cdata, maxlen)
OverflowError: long int too large to convert to int

This is on ubuntu 10.04 i686. The libpypy-c is built locally to match up with libssh version and libffi etc..

if you need more action in order to debug please let me know

Here is a toy setup that brought me to a segfault. I probably do something wrong, but I was asked on twitter to report this so here is the story:

I'm trying to run django instances in a multiapp setup, in order to not have to decide how many workers per instance (is that a correct assumption?).
I followed the tutorial at https://uwsgi-docs.readthedocs.org/en/latest/Python.html?highlight=applications but this just didn't work, because there is no such a uwsgi python module (I did installed it using pip).
So I did things my way, with my current understanding of how it works:

master.py:

application = {
  '': 'django1.django1.wsgi.application',
  '/django2': 'django2.django2.wsgi.application',
  '/django3': 'django3.django3.wsgi.application',
}

And here comes the segfault:

uwsgi --pp=~/.virtualenvs/multi-django/lib/python2.7/site-packages/ --pp=. -s 127.0.0.1:3030 --master --module=master
*** Starting uWSGI 1.9.18.1 (64bit) on [Thu Oct 17 11:03:21 2013] ***
compiled with version: 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) on 16 October 2013 17:45:16
os: Darwin-11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64
nodename: danode
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /Users/daboy/src/multi-django
detected binary path: /Users/daboy/.virtualenvs/multi-django/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
your processes number limit is 709
your memory page size is 4096 bytes
detected max file descriptor number: 2560
lock engine: OSX spinlocks
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address 127.0.0.1:3030 fd 3
Python version: 2.7.5 (default, Jun  3 2013, 13:05:43)  [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x7fe393c0ba60
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 145568 bytes (142 KB) for 1 cores
*** Operational MODE: single process ***
added ~/.virtualenvs/multi-django/lib/python2.7/site-packages/ to pythonpath.
added ./ to pythonpath.
found a multiapp module...
!!! uWSGI process 42635 got Segmentation Fault !!!
*** backtrace of 42635 ***
0   uwsgi                               0x0000000104da2e42 uwsgi_backtrace + 50
1   uwsgi                               0x0000000104da2901 uwsgi_segfault + 49
2   libsystem_c.dylib                   0x00007fff8361acfa _sigtramp + 26
3   ???                                 0x7300000100000073 0x0 + 8286623318656680051
4   uwsgi                               0x0000000104dad66f uwsgi_python_init_apps + 655
5   uwsgi                               0x0000000104d9cdc3 uwsgi_init_all_apps + 211
6   uwsgi                               0x0000000104d9f774 uwsgi_start + 4612
7   uwsgi                               0x0000000104da27ef main + 9919
8   uwsgi                               0x0000000104d5e3e4 start + 52
9   ???                                 0x0000000000000007 0x0 + 7
*** end of backtrace ***

From the documentation is not clear that at and priority parameters exist at all.

--check-static check for static files in the specified directory
--check-static-docroot check for static files in the requested DOCUMENT_ROOT
--static-check check for static files in the specified directory
--static-map map mountpoint to static directory (or file)
--static-map2 like static-map but completely appending the requested resource to the docroot
--static-skip-ext skip specified extension from staticfile checks
--static-index search for specified file if a directory is requested
--static-expires-type set the Expires header based on content type
--static-expires-type-mtime set the Expires header based on content type and file mtime
--static-expires set the Expires header based on filename regexp
--static-expires-mtime set the Expires header based on filename regexp and file mtime
--static-expires-uri set the Expires header based on REQUEST_URI regexp
--static-expires-uri-mtime set the Expires header based on REQUEST_URI regexp and file mtime
--static-expires-path-info set the Expires header based on PATH_INFO regexp
--static-expires-path-info-mtime set the Expires header based on PATH_INFO regexp and file mtime
--static-offload-to-thread offload static file serving to a thread (upto the specified number of threads)
--file-serve-mode set static file serving mode
--fileserve-mode set static file serving mode

https://github.com/unbit/uwsgi-docs/blob/master/SystemD.rst#putting-sockets-in-run
uses ExecStartPre to create /run/uwsgi.
I suggest it is better to create /etc/tmpfiles.d/emperor.uwsgi.conf:

d /run/uwsgi 0755 www-data www-data -