Roberto De Ioris | 28 Jan 14:40 2015

[ANNOUNCE] uwsgi-sentry plugin

Hi everyone, as promised, a sentry ( plugin for uWSGI is now



Roberto De Ioris
Roberto De Ioris | 8 Jan 20:56 2015

[OT] SpockFS sneak preview

(Sorry for the OT)

We just released SpockFS an HTTP-based network filesystem (xml-free :P)

The repository contains SPECS 0.1, a FUSE client and a uWSGI plugin for
running servers.

I hope you will find it useful



Roberto De Ioris
Robin Bowes | 31 Dec 21:06 2014

Problem setting additional groups


I'm using uwsgi 2.0.9 on CentOS 7, built from the Fedora 21 2.0.7 packages. SRPM and RPM are here:

uwsgi is run under systemd in emperor mode. This is the main config I'm using (/etc/uwsgi.ini):

uid = uwsgi
gid = uwsgi
pidfile = /run/uwsgi/
emperor = /etc/uwsgi.d
stats = /run/uwsgi/stats.sock
emperor-tyrant = true
emperor-tyrant-initgroups = true
cap = setgid,setuid

I'm running the puppetboard app as a vassal with the following config (/etc/uwsgi.d/puppetboard.ini):

plugins = python
http-socket = :8080
wsgi-file = /var/www/puppetboard/
uid = puppetboard
gid = puppetboard
enable-threads = true
thunder-lock = true

Ownership on puppetboard.ini is puppetboard:puppetboard

The puppetboard user is also a member of the puppet group. This is so puppetboard can read a cert key from /var/lib/puppet/ssl/private_keys/ as there are directories in that path that are mode 0750 and with ownership by puppet:puppet

However, the additional group is not getting set on the puppetboard.ini app processes - they just get puppetboard:puppetboard and consequently they are not able to read the puppet certs.

From top:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                               GROUP    SUPGRPS
 1293 puppetb+  20   0  333616   5864   1796 S  0.0  0.2   0:00.06 httpd                                                 puppetb+ puppet,puppetboard
 1460 puppetb+  20   0  243400  19352   5112 S  0.0  0.5   0:00.28 uwsgi                                                 puppetb+ -
 1467 puppetb+  20   0  249512  19072   3604 S  0.0  0.5   0:00.12 uwsgi                                                 puppetb+ -

The process that *does* have the correct supplementary groups is the same app running under apache and mod_wsgi.

Am I configuring this wrongly, or is this a bug?


uWSGI mailing list
Roberto De Ioris | 30 Dec 17:11 2014

[ANNOUNCE] uwsgi-sse-offload

Hi, this is a fork of the uwsgi-realtime project with only the SSE
features exposed.

This plugin allows you to build SSE (server sent events) apps pretty fast
and without bothering about blocking/non-blocking as the whole system is
offload based.

The trick is using redis as the communication channel. Whenever a message
is published on a specific channel, all of the sse peers connected to that
channel will receive the message.

You can get it (and read the docs) here:


Roberto De Ioris
Roberto De Ioris | 30 Dec 07:06 2014


Hi all, a new (tiny) LTS release is available:

interesting stuffs are the improved (and easier to use) PyPy support, the
fastrouter post-buffering mode and various perl improvements.

oh, and happy new year



Roberto De Ioris
Thomas Larsen Wessel | 19 Dec 11:42 2014

pip uninstall uwsgi, leaves /usr/local/bin/uwsgi

I guess this is a bug, or what? And I could not figure out where to report it, so now I'm trying here.

It caused me some headache. I was in a virtualenv with a uwsgi installation, I uninstalled it from the virtualenv, but the local executable uwsgi remained. So when I thought I was running the global, I was running the local, which meant unexpected values for home and cwd (I think).
uWSGI mailing list
Simon | 15 Dec 22:10 2014

uwsgi c-ares plugin build error

I get this error while building the c-ares plugin:

[gcc -pthread]
/uwsgi-cares/dns.c: In function 'cares_register':
/uwsgi-cares/dns.c:191:12: error: dereferencing pointer to incomplete type
*** unable to build cares plugin ***

I'm building inside a docker container running debian-wheezy and libc-ares-dev is installed. Uwsgi version is 2.0.8.

uWSGI mailing list
Roberto De Ioris | 12 Dec 06:56 2014

implemented uwsgi::opt in perl

Hi, the perl/psgi plugin now exposes the uwsgi::opt hashref that contains
all the options set in the current instance:

$VAR1 = {
          'logdate' => '%d',
          'master' => 1,
          'psgi' => '',
          'http-socket' => [
          'socket' => [
          'processes' => '2'

The patch has been applied to both master and uwsgi-2.0 (will be in 2.0.9)



Roberto De Ioris
Jean-Baptiste Quenot | 8 Dec 16:52 2014

Content-Length woes between uwsgi/php and nginx

Hello fellow UWSGI supporters,

I'm struggling with an issue in my PHP software (namely Pimcore).

The PHP stuff is served through an Haproxy -> Nginx -> UWSGI stack that runs without a hitch since 18 months.

A few days ago, after a Pimcore software update to version 2.3.0, users reported corrupted file downloads, and I noticed something weird with Content-Length.  Let me illustrate the problem with an example from the logs.

From uwsgi logs:

[pid: 15215|app: -1|req: -1/15] () {32 vars in 567 bytes} [Mon Dec  8 14:58:50 2014] GET /admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true => generated 13950 bytes in 4364 msecs (HTTP/1.1 200) 8 headers in 256 bytes (0 switches on core 0)

From nginx logs: - - [08/Dec/2014:14:58:54 +0100] "GET /admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true HTTP/1.1" 200 12032 "-" "curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/ libidn/1.23 librtmp/2.3"

As you can see there is a discrepancy between the response length reported by uwsgi, and the one from nginx.  It should be the same.

The output of curl is also surprising:

curl -i -b pimcore_admin_sid=something http://localhost/admin/asset/get-image-thumbnail/id/8280/treepreview/true_dc=1418043520956/download/true
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Mon, 08 Dec 2014 13:58:54 GMT
Content-Type: image/pjpeg
Content-Length: 2
Connection: keep-alive
Content-Disposition: attachment; filename="320.336g-1.pjpeg"
Cache-Control: public, max-age=300
Expires: Mon, 08 Dec 2014 15:03:54 +0100
X-Powered-By: pimcore

As you can see the reported Content-Length this time is 2 bytes!  And please notice there are two blank lines in the response.

How is it possible that the Content-Length is different in three places?

I couldn't find a way to make this problem 100% reproducible, so this is particularly difficult to resolve.

Your help would be appreciated to narrow down what is causing this.

UWSGI config file:
Nginx config file:

Best regards,
Jean-Baptiste Quenot

uWSGI mailing list
Manivel Rajendran | 4 Dec 07:52 2014

nginx+uwsgi+django, there seems to be some strange cache in uwsgi

      The django works fine, but modified pages can't be seen unless i restart uwsgi. i didn't config anything about cache.

      It works well with "python manager runserver", but have this problem when working with nginx+uwsgi.

      This is my "uwsgi.ini" file


     Kindly help me.

Thanks & Regards

Manivel Rajendran

uWSGI mailing list
Jacob Rief | 3 Dec 10:46 2014

Routing to websocket using a named unix socket

Unfortunately I'am unable to get uWSGI's router, proxying my websocket request to a uWSGI instance listening on a named unix socket.

In my configuration I have an emperor spawning two vassals. One vassal serves normal Django requests, while the other vassal serves Websockets requests. They both own a separate named Unix socket.

Currently nginx forwards requests to these two sockets and this works fine. The nginx configuration inside a server section looks like this:

server {

    location / {
        include /opt/local/etc/nginx/uwsgi_params;
        uwsgi_pass unix:/var/tmp/django.socket;

    location /ws/ {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_pass http://unix:/var/tmp/web.socket;

Now I wanted to replace nginx by uWSGI itself and use its own routing mechanism. For normal web requests this works fine and inside my configuration I have

[uwsgi]emperor = vassals

http-socket = :9090

#no-orphans = true

#threads = 1

#die-on-term = true

http-websockets = true

route = ^/ws http:unix:/var/tmp/web.socket

route = ^/ uwsgi:/var/tmp/django.socket,0,0

uWSGI mailing list