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

Clemens Kolbitsch kolbitsch at lastline.com
Tue Apr 8 07:55:43 CEST 2014


Hi!

create_app is called within the wsgi file (that is, immediately)

-Clemens

On Mon, Apr 7, 2014 at 10:42 PM, Roberto De Ioris <roberto at unbit.it> wrote:

>
> > 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
> _______________________________________________
> uWSGI mailing list
> uWSGI at lists.unbit.it
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>



-- 
Clemens Kolbitsch
Security Researcher
kolbitsch at lastline.com
Mobile +1 (206) 356-7745
Land +1 (805) 456-7076

Lastline, Inc.
6950 Hollister Avenue, Suite 101
Goleta, CA 93117

www.lastline.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.unbit.it/pipermail/uwsgi/attachments/20140407/59d0aae7/attachment-0001.html>


More information about the uWSGI mailing list