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

Roberto De Ioris roberto at unbit.it
Wed Apr 9 11:40:09 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
>
>

can you repeat the test printing the process pid (os.getpid()) at each
line ? in this way we can see if all the stages are executed before the
"readyness" announce

Thanks

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


More information about the uWSGI mailing list