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

Clemens Kolbitsch kolbitsch at lastline.com
Tue Apr 8 20:22:46 CEST 2014


I modified the code as follows:

[...]
print "loading stage 1"
application = myapp.create_app(CONFIG_FILE, None, log, strict=True)
print "loading stage 2"
application.logger.setLevel(logging.DEBUG)
for handler in log.logger().handlers:
    application.logger.addHandler(handler)
print "loading stage 3"

and get the following logs

/usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini 2>&1 | grep -v
HTTP.....200
[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/myapp.ini
*** Starting uWSGI 2.0.3 (64bit) on [Tue Apr  8 18:16:20 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 0x1d5d480
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: 19627)
spawned uWSGI worker 1 (pid: 19629, cores: 75)
spawned uWSGI worker 2 (pid: 19630, cores: 75)
loading stage 1
loading stage 1
loading stage 2
loading stage 2
loading stage 3
loading stage 3

[...]

worker 2 killed successfully (pid: 22063)
Respawned uWSGI worker 2 (new pid: 22494)
worker 1 killed successfully (pid: 22064)
Respawned uWSGI worker 1 (new pid: 22495)
loading stage 1
loading stage 1
loading stage 2
loading stage 3
loading stage 2
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid:
22494 (default app)
loading stage 3
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid:
22495 (default app)

[...]

...The work of process 22494 is done. Seeya!
...The work of process 22495 is done. Seeya!
worker 2 killed successfully (pid: 22494)
Respawned uWSGI worker 2 (new pid: 22685)
worker 1 killed successfully (pid: 22495)
Respawned uWSGI worker 1 (new pid: 22686)
loading stage 1
loading stage 1
loading stage 2
loading stage 2
loading stage 3
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid:
22686 (default app)
loading stage 3
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid:
22685 (default app)
[pid: 22685|app: 0|req: 3/4660] 192.168.100.11 () {32 vars in 432 bytes}
[Tue Apr  8 18:18:07 2014] GET /myapp/... => generated 238 bytes in 6 msecs
(HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 0)
[pid: 22686|app: 0|req: 16/4665] 192.168.100.11 () {32 vars in 432 bytes}
[Tue Apr  8 18:18:07 2014] GET /myapp/... => generated 238 bytes in 26
msecs (HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 5)
[pid: 22686|app: 0|req: 54/4677] 192.168.100.11 () {32 vars in 432 bytes}
[Tue Apr  8 18:18:07 2014] GET /myapp/... => generated 238 bytes in 56
msecs (HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 7)
[pid: 22686|app: 0|req: 54/4678] 192.168.100.11 () {32 vars in 432 bytes}
[Tue Apr  8 18:18:07 2014] GET /myapp/... => generated 238 bytes in 58
msecs (HTTP/1.1 404) 2 headers in 72 bytes (1 switches on core 1)

after this, the logs are empty again - that is, no more 404s for a while
(note that I grep out the HTTP-200s before and after)

thanks!
-Clemens



On Tue, Apr 8, 2014 at 9:50 AM, Roberto De Ioris <roberto at unbit.it> wrote:

>
> > Hi,
> >
> > thanks for the advice. I tried that and it did not make a difference :(
> > (and, just to make sure, I'm using "lazy-apps" [not the S at the end] )
> >
> > -Clemens
>
>
> I do not think it is something uWSGI-specific, can you add a "print
> 'something'" at teh end of the create_app procesudre to check if it
> ihappens boefore or after the threads are spawned ?
>
> >
> >
> > On Tue, Apr 8, 2014 at 9:39 AM, INADA Naoki <songofacandy at gmail.com>
> > wrote:
> >
> >> lazy option is discouraged.
> >> lazy-app option may help you.
> >>
> >> On Wed, Apr 9, 2014 at 1:06 AM, Clemens Kolbitsch
> >> <kolbitsch at lastline.com> wrote:
> >> > On Tue, Apr 8, 2014 at 3:13 AM, Roberto De Ioris <roberto at unbit.it>
> >> wrote:
> >> >>
> >> >>
> >> >> > import ConfigParser
> >> >> > import logging
> >> >> >
> >> >> > import myapp
> >> >> >
> >> >> >
> >> >> > CONFIG_FILE = "/etc/myapp/myapp.ini"
> >> >> >
> >> >> > config_parser = ConfigParser.ConfigParser()
> >> >> > config_file = open(CONFIG_FILE)
> >> >> > config_parser.readfp(config_file,CONFIG_FILE)
> >> >> >
> >> >> > log = ...
> >> >> > application = myapp.create_app(CONFIG_FILE, None, log, strict=True)
> >> >> >
> >> >> > application.logger.setLevel(logging.DEBUG)
> >> >> > for handler in log.logger().handlers:
> >> >> >     application.logger.addHandler(handler)
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> I see nothing strange in it, but once you get 404 you continue to get
> >> it
> >> >> or it get fixed after a bunch of requests ?
> >> >
> >> >
> >> > the 404 happens right after the respawning, happens 1-2 times and goes
> >> away
> >> > again (probably once the blueprints have been properly loaded)
> >> >
> >> > -Clemens
> >> >
> >> >
> >> > _______________________________________________
> >> > uWSGI mailing list
> >> > uWSGI at lists.unbit.it
> >> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >> >
> >>
> >>
> >>
> >> --
> >> INADA Naoki  <songofacandy at gmail.com>
> >> _______________________________________________
> >> 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
> > _______________________________________________
> > uWSGI mailing list
> > uWSGI at lists.unbit.it
> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >
>
>
> --
> 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/20140408/4ddca4d6/attachment-0001.html>


More information about the uWSGI mailing list