[uWSGI] Possible setup race condition between uwsgi-plugin-python and python-flask

Roberto De Ioris roberto at unbit.it
Tue Apr 8 07:42:18 CEST 2014


> Hi,
>
> ok, some more tests later, I can still reproduce the problem :( To me it
> *feels* like it happens less frequently, but it still happens. More
> information about the setup:
>
> # uwsgi --version
> 2.0.3
>
> # /usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini
> [uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/myapp.ini
> *** Starting uWSGI 2.0.3 (64bit) on [Tue Apr  8 02:54:48 2014] ***
> compiled with version: 4.6.3 on 08 April 2014 02:43:31
> os: Linux-3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014
> nodename: mynode
> machine: x86_64
> clock source: unix
> detected number of CPU cores: 8
> current working directory: /var/log
> detected binary path: /usr/local/bin/uwsgi
> !!! no internal routing support, rebuild with pcre support !!!
> setgid() to 1010
> setuid() to 1002
> your processes number limit is 128020
> 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 127.0.0.1:4003 fd 3
> Python version: 2.7.3 (default, Feb 27 2014, 20:09:21)  [GCC 4.6.3]
> Python main interpreter initialized at 0xa4b480
> python threads support enabled
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> mapped 2503992 bytes (2445 KB) for 150 cores
> *** Operational MODE: preforking+threaded ***
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI master process (pid: 16816)
> spawned uWSGI worker 1 (pid: 16828, cores: 75)
> spawned uWSGI worker 2 (pid: 16829, cores: 75)
> WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0xa4b480 pid:
> 16829 (default app)
> WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0xa4b480 pid:
> 16828 (default app)
>
> My config:
>
> [uwsgi]
> master      = 1
> workers     = 2
> threads     = 75
> max-requests = 100
> listen = 100
> socket      = 127.0.0.1:4003
> file        = /usr/bin/myapp.wsgi
> callable    = application
> chdir       = /var/lib/myapp/
> uid         = myapp
> gid         = myapp_group
> lazy        = 1
>

Hi Clemens, i have re-read your previous post to understand your structure.

There is something not clear:

are the apps created at the first request, or from the WSGI entrypoint ?

i mean, when create_app() is called ?

The WSGI entry point is loaded before all of the threads are spawned, and
so you should not have this problem. But if you start adding apps directly
in a thread (during a request phase), the behaviour you get is expected
(but you can easily fix it with locking)

-- 
Roberto De Ioris
http://unbit.it


More information about the uWSGI mailing list