Roberto De Ioris | 7 Oct 09:03 2015


Hi Everyone,

uWSGI has been released.

It fixes a bunch of minor bugs and includes support for OSX 10.11

Thanks to all the contributors

Roberto De Ioris
Riccardo Magliocchetti | 2 Oct 19:03 2015

finer grained resolution timer for python plugin


i'd like to add a finer grained resolution timer to the python plugin. I need 
millisecond resolution. What do you think?



Riccardo Magliocchetti
 <at> rmistaken
Ben Roberts | 2 Oct 18:42 2015

Failure to install uwsgi via pip : use of undeclared identifier 'SOL_TCP'

after upgrade to OSX 10.11 (El Capitan), uwsgi fails to install. Any ideas how to resolve this?

>: pip install uwsgi
Downloading/unpacking uwsgi
  Downloading uwsgi- (782kB): 782kB downloaded
  Running egg_info for package uwsgi
Installing collected packages: uwsgi
  Running install for uwsgi
    core/socket.c:713:28: error: use of undeclared identifier 'SOL_TCP'
                    if (setsockopt(serverfd, SOL_TCP, TCP_FASTOPEN, (const void *) &uwsgi.tcp_fast_open, sizeof(int)) < 0) {
    1 error generated.
    Complete output from command /Users/sean/Envs/test/bin/python -c "import setuptools;__file__='/Users/sean/Envs/test/build/uwsgi/';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/8k/b4793zyx0p1gb_5j2h0yk4n40000gq/T/pip-dcXb53-record/install-record.txt --single-version-externally-managed --install-headers /Users/sean/Envs/test/bin/../include/site/python2.7:
    running install

core/socket.c:713:28: error: use of undeclared identifier 'SOL_TCP'

                if (setsockopt(serverfd, SOL_TCP, TCP_FASTOPEN, (const void *) &uwsgi.tcp_fast_open, sizeof(int)) < 0) {


1 error generated.\

uWSGI mailing list
David Montgomery | 30 Sep 08:10 2015

!! UNABLE to load uWSGI plugin: ./ cannot open shared object file: No such file or directory !!!


How do I resolve this error?
I am on ubuntu 14.04 using python 2x

here is how I install: UWSGI_EMBED_PLUGINS=msgpack pip install uwsgi==

/usr/local/bin/uwsgi --yaml /var/uwsgi.graphite.yaml
[uWSGI] getting YAML configuration from /var/uwsgi.graphite.yaml
open("./"): No such file or directory [core/utils.c line 3653]
!!! UNABLE to load uWSGI plugin: ./ cannot open shared object file: No such file or directory !!!
*** Starting uWSGI (64bit) on [Wed Sep 30 02:07:09 2015] ***
compiled with version: 4.8.4 on 30 September 2015 01:43:24
os: Linux-3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015
nodename: do-monitor-sf-development-20150930053552
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/supervisor/conf.d
writing pidfile to /var/run/
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 

uWSGI mailing list
Lele Gaifax | 27 Sep 23:50 2015

Is Python 3.5 supported?

Hi all,

I have a very simple Flask application exposed to nginx thru uwsgi.
It works great up to Python 3.4, but with Python 3.5 I get this error:

    ERROR:raccoon.thumbnailer:Exception on /adapt [GET]
    io.UnsupportedOperation: fileno

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/usr/local/lib/python3.5/site-packages/flask/", line 1817, in wsgi_app
        response = self.full_dispatch_request()
      File "/usr/local/lib/python3.5/site-packages/flask/", line 1477, in full_dispatch_request
        rv = self.handle_user_exception(e)
      File "/usr/local/lib/python3.5/site-packages/flask/", line 1381, in handle_user_exception
        reraise(exc_type, exc_value, tb)
      File "/usr/local/lib/python3.5/site-packages/flask/", line 33, in reraise
        raise value
      File "/usr/local/lib/python3.5/site-packages/flask/", line 1475, in full_dispatch_request
        rv = self.dispatch_request()
      File "/usr/local/lib/python3.5/site-packages/flask/", line 1461, in dispatch_request
        return self.view_functions[rule.endpoint](**req.view_args)
      File "/srv/app/src/raccoon/thumbnailer/", line 88, in adapt_requested_image
        return send_file(f, mimetype='image/png')
      File "/usr/local/lib/python3.5/site-packages/flask/", line 523, in send_file
        data = wrap_file(request.environ, file)
      File "/usr/local/lib/python3.5/site-packages/werkzeug/", line 716, in wrap_file
        return environ.get('wsgi.file_wrapper', FileWrapper)(file, buffer_size)
    SystemError: <built-in function uwsgi_sendfile> returned a result with an error set

Is it a known problem or some kind of fault of mine?

Thanks in advance,
bye, lele.

nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele <at>  |                 -- Fortunato Depero, 1929.

uWSGI mailing list
uWSGI <at>
Daurnimator | 23 Sep 14:13 2015

Missing uwsgi.suspend() in lua plugin?


I'm trying out the lua plugin. I'd like to yield in my handler until
an fd polls readable.
I can happily call `uwsgi.wait_fd_read(myfd, mytimeout)`, but this
doesn't actually **do** the waiting.
Looking at the python bindings, it appears you're meant to call
`uwsgi.suspend()` after you set-up your fds.
However, `uwsgi.suspend()` doesn't seem to exist in the lua bindings.
is the list of functions exposed.

paivamonteiro75 | 17 Sep 10:18 2015

Log of uwsgi


I installed uwsgi in Linux SO with Apache Webserver, i can't trace the problem with uwsgi configuration :


socket = /tmp/sup.epa.sock
master = True
pcre-jit = on
thunder-lock = on
daemonize = /var/log/uwsgi/app.log
log-reopen = true
chmod-socket = 664
gid = www-data
uid = www-data

And the comands i use to stop and restart uwsgi is the following :

echo '********* kill instance ******************'
sudo kill -HUP `cat /tmp/`
uwsgi --reload /tmp/
sudo touch /tmp/app.sock

uwsgi --emperor /etc/uwsgi/vassals/

The output of the log is the following :

*** Starting uWSGI (64bit) on [Thu Sep 17 08:09:19 2015] ***
compiled with version: 4.8.2 on 23 March 2014 17:15:32
os: Linux-3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015
nodename: ip-10-0-0-7
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/bin/uwsgi-core
your processes number limit is 30038
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: enabled
unlink(): Operation not permitted [core/socket.c line 135]
bind(): Address already in use [core/socket.c line 185]

I can't understand some things in the output of the log, the pcre jit is enabled in the configuration, but the two last lines i can't trace the error.

Best regards, 





uWSGI mailing list
laada | 16 Sep 16:20 2015

Re: overloading of harakiri

Dne 16.9.2015 v 14:44 uwsgi-request@... napsal(a):
> ------------------------------ Message: 3 Date: Wed, 16 Sep 2015 
> 13:53:31 +0200 From: "Roberto De Ioris" <roberto@...> To: "uWSGI 
> developers and users list" <uwsgi@...> Subject: Re: [uWSGI] 
> overloading of harakiri Message-ID: 
> <90c54b3f394a8dcd580246c1b1963e7c.squirrel@...> 
> Content-Type: text/plain;charset=utf-8
>> >Hi all,
>> >I have problem with overloading of harakiri setting in config file by
>> >python uwsgidecorator.
>> >
>> >*uwsgi.ini:*
>> >
>> >[uwsgi]
>> >...
>> >
>> >harakiri = 5
>> >harakiri-verbose
>> >
>> >...
>> >
>> >
>> >*tasksfile:*
>> >
>> > <at> filemon('/some/dir')
>> > <at> harakiri(60)
>> >def fce(*args):
>> >      some code
>> >
>> >
> you can lower it, but not increase (for security reasons).
> You can bypass it and use only "user-governed" harakiri, via the internal
> routing framework:
> ; blindly set harakiri for all the urls
> route-run = harakiri:xxx
> -- Roberto De Ioris
it works!!

thanx a lot
laada | 16 Sep 13:51 2015

overloading of harakiri

Hi all,
I have problem with overloading of harakiri setting in config file by 
python uwsgidecorator.



harakiri = 5


*tasks file:*

 <at> filemon('/some/dir')
 <at> harakiri(60)
def fce(*args):
     some code

Processing of fce() always die after 5 sec.
I also tried use uwsgi.set_user_harakiri(60) but with same effect.

Is it somehow possible overload general setting of harakiri?

thanx for help
Руслан Закиров | 16 Sep 12:37 2015

two requests are merged into one when reach async psgi app


Short summary:

My async psgi application from time to time gets request environment with two set of headers from different HTTP requests combined into one.

Longer version:

nginx in front proxy passing requests to uwsgi back-end running app with psgi and coroae plugins. I can not reproduce this problem in isolated environment, so I only have set of logs from fronts and backs.

Two requests on one front-end:

[15/Sep/2015:14:41:15 +0300] "GET /tennis/fedcup/ HTTP/1.1" 200 70202 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +" "" MISS [0.406, 1.254] 1.669 {,} 282
[15/Sep/2015:14:41:15 +0300] "GET / HTTP/1.1" 404 16404 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/600.7.12 (KHTML, like Gecko) Version/6.2.7 Safari/537.85.16" "" HIT [0.010] 0.011 {} 1758

Both hit .42 backend, first request got some error response and bounced to another backend for retry.

On the backend in uwsgi access log I see only one request:

[pid: 10585|app: 0|req: 100077/199815] () {72 vars in 2526 bytes} [Tue Sep 15 14:41:15 2015] GET /desktop/ => generated 9 bytes in 8 msecs (HTTP/1.0 404) 1 headers in 67 bytes (1 switches on core 127)

In app's log I see the following:

request for /desktop/tennis/fedcup/, /desktop/ on,

App logs $env->{REQUEST_URI} and $env->{HTTP_HOST} at the beginning.

From psgi's plugin source code I see that if a header repeated multiple times in the request then into perl world it gets as comma separated record in the environment hash. This is why I made conclusion that these are two requests combined into one.

Any ideas on why this is happening? On how to debug this? reproduce?

PS: It may be related to harikiri. We don't have harakiri log entries in these logs, but they show up on a console and we feel that they are related to this problem.

Руслан Закиров
Руководитель отдела разработки веб-сервисов
+7(916) 597-92-69, ruz  <at>  
uWSGI mailing list
Salatiel Filho | 12 Sep 03:46 2015

error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

Hello guys, i am trying to compile uwsgi for my openwrt router but it
always fails with:

 #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
In file included from
                 from plugins/python/uwsgi_python.h:2,
                 from plugins/python/wsgi_handlers.c:1:
error: #error "LONG_BIT definition appears wrong for platform (bad
gcc/glibc config?)."
 #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc
Makefile:50: recipe for target

I have no idea how to fix this. Any help ? Thanks!