<div dir="ltr">I modified the code as follows:<div><br></div><div>[...]</div><div><div>print "loading stage 1"</div><div>application = myapp.create_app(CONFIG_FILE, None, log, strict=True)</div><div>print "loading stage 2"</div>

<div>application.logger.setLevel(logging.DEBUG)</div><div>for handler in log.logger().handlers:</div><div>    application.logger.addHandler(handler)</div><div>print "loading stage 3"</div></div><div><br></div><div>

and get the following logs</div><div><br></div><div>/usr/bin/uwsgi --ini /etc/uwsgi/apps-enabled/myapp.ini 2>&1 | grep -v HTTP.....200<br></div><div><div>[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/myapp.ini</div>

<div>*** Starting uWSGI 2.0.3 (64bit) on [Tue Apr  8 18:16:20 2014] ***</div><div>compiled with version: 4.6.3 on 08 April 2014 02:43:31</div><div>os: Linux-3.2.0-60-generic #91-Ubuntu SMP Wed Feb 19 03:54:44 UTC 2014</div>

<div>nodename: mynode</div><div>machine: x86_64</div><div>clock source: unix</div><div>detected number of CPU cores: 8</div><div>current working directory: /var/log</div><div>detected binary path: /usr/local/bin/uwsgi</div>

<div>!!! no internal routing support, rebuild with pcre support !!!</div><div>setgid() to 1010</div><div>setuid() to 1002</div><div>your processes number limit is 128020</div><div>your memory page size is 4096 bytes</div>

<div>detected max file descriptor number: 1024</div><div>lock engine: pthread robust mutexes</div><div>thunder lock: disabled (you can enable it with --thunder-lock)</div><div>uwsgi socket 0 bound to TCP address <a href="http://127.0.0.1:4003">127.0.0.1:4003</a> fd 3</div>

<div>Python version: 2.7.3 (default, Feb 27 2014, 20:09:21)  [GCC 4.6.3]</div><div>Python main interpreter initialized at 0x1d5d480</div><div>python threads support enabled</div><div>your server socket listen backlog is limited to 100 connections</div>

<div>your mercy for graceful operations on workers is 60 seconds</div><div>mapped 2503992 bytes (2445 KB) for 150 cores</div><div>*** Operational MODE: preforking+threaded ***</div><div>*** uWSGI is running in multiple interpreter mode ***</div>

<div>spawned uWSGI master process (pid: 19627)</div><div>spawned uWSGI worker 1 (pid: 19629, cores: 75)</div><div>spawned uWSGI worker 2 (pid: 19630, cores: 75)</div><div>loading stage 1</div><div>loading stage 1</div><div>

loading stage 2</div><div>loading stage 2</div><div>loading stage 3</div><div>loading stage 3</div></div><div><br></div><div>[...]</div><div><br></div><div><div>worker 2 killed successfully (pid: 22063)</div><div>Respawned uWSGI worker 2 (new pid: 22494)</div>

<div>worker 1 killed successfully (pid: 22064)</div><div>Respawned uWSGI worker 1 (new pid: 22495)</div><div>loading stage 1</div><div>loading stage 1</div><div>loading stage 2</div><div>loading stage 3</div><div>loading stage 2</div>

<div>WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid: 22494 (default app)</div><div>loading stage 3</div><div>WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid: 22495 (default app)</div>

<div><div><br class="">[...]</div></div><div><br></div><div>...The work of process 22494 is done. Seeya!</div><div>...The work of process 22495 is done. Seeya!</div><div>worker 2 killed successfully (pid: 22494)</div><div>

Respawned uWSGI worker 2 (new pid: 22685)</div><div>worker 1 killed successfully (pid: 22495)</div><div>Respawned uWSGI worker 1 (new pid: 22686)</div><div>loading stage 1</div><div>loading stage 1</div><div>loading stage 2</div>

<div>loading stage 2</div><div>loading stage 3</div><div>WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid: 22686 (default app)</div><div>loading stage 3</div><div>WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1d5d480 pid: 22685 (default app)</div>

<div>[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)</div>

<div>[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)</div>

<div>[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)</div>

<div>[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)</div>

</div><div><br></div><div>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)</div><div><br></div><div>thanks!</div><div>-Clemens</div><div><br></div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 9:50 AM, Roberto De Ioris <span dir="ltr"><<a href="mailto:roberto@unbit.it" target="_blank">roberto@unbit.it</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> Hi,<br>
><br>
> thanks for the advice. I tried that and it did not make a difference :(<br>
> (and, just to make sure, I'm using "lazy-apps" [not the S at the end] )<br>
><br>
> -Clemens<br>
<br>
<br>
</div>I do not think it is something uWSGI-specific, can you add a "print<br>
'something'" at teh end of the create_app procesudre to check if it<br>
ihappens boefore or after the threads are spawned ?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Tue, Apr 8, 2014 at 9:39 AM, INADA Naoki <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>><br>
> wrote:<br>
><br>
>> lazy option is discouraged.<br>
>> lazy-app option may help you.<br>
>><br>
>> On Wed, Apr 9, 2014 at 1:06 AM, Clemens Kolbitsch<br>
>> <<a href="mailto:kolbitsch@lastline.com">kolbitsch@lastline.com</a>> wrote:<br>
>> > On Tue, Apr 8, 2014 at 3:13 AM, Roberto De Ioris <<a href="mailto:roberto@unbit.it">roberto@unbit.it</a>><br>
>> wrote:<br>
>> >><br>
>> >><br>
>> >> > import ConfigParser<br>
>> >> > import logging<br>
>> >> ><br>
>> >> > import myapp<br>
>> >> ><br>
>> >> ><br>
>> >> > CONFIG_FILE = "/etc/myapp/myapp.ini"<br>
>> >> ><br>
>> >> > config_parser = ConfigParser.ConfigParser()<br>
>> >> > config_file = open(CONFIG_FILE)<br>
>> >> > config_parser.readfp(config_file,CONFIG_FILE)<br>
>> >> ><br>
>> >> > log = ...<br>
>> >> > application = myapp.create_app(CONFIG_FILE, None, log, strict=True)<br>
>> >> ><br>
>> >> > application.logger.setLevel(logging.DEBUG)<br>
>> >> > for handler in log.logger().handlers:<br>
>> >> >     application.logger.addHandler(handler)<br>
>> >> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >> I see nothing strange in it, but once you get 404 you continue to get<br>
>> it<br>
>> >> or it get fixed after a bunch of requests ?<br>
>> ><br>
>> ><br>
>> > the 404 happens right after the respawning, happens 1-2 times and goes<br>
>> away<br>
>> > again (probably once the blueprints have been properly loaded)<br>
>> ><br>
>> > -Clemens<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > uWSGI mailing list<br>
>> > <a href="mailto:uWSGI@lists.unbit.it">uWSGI@lists.unbit.it</a><br>
>> > <a href="http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi" target="_blank">http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> INADA Naoki  <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>><br>
>> _______________________________________________<br>
>> uWSGI mailing list<br>
>> <a href="mailto:uWSGI@lists.unbit.it">uWSGI@lists.unbit.it</a><br>
>> <a href="http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi" target="_blank">http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Clemens Kolbitsch<br>
> Security Researcher<br>
> <a href="mailto:kolbitsch@lastline.com">kolbitsch@lastline.com</a><br>
> Mobile <a href="tel:%2B1%20%28206%29%20356-7745" value="+12063567745">+1 (206) 356-7745</a><br>
> Land <a href="tel:%2B1%20%28805%29%20456-7076" value="+18054567076">+1 (805) 456-7076</a><br>
><br>
> Lastline, Inc.<br>
> 6950 Hollister Avenue, Suite 101<br>
> Goleta, CA 93117<br>
><br>
> <a href="http://www.lastline.com" target="_blank">www.lastline.com</a><br>
> _______________________________________________<br>
> uWSGI mailing list<br>
> <a href="mailto:uWSGI@lists.unbit.it">uWSGI@lists.unbit.it</a><br>
> <a href="http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi" target="_blank">http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi</a><br>
><br>
<br>
<br>
--<br>
</div></div><div class="im HOEnZb">Roberto De Ioris<br>
<a href="http://unbit.it" target="_blank">http://unbit.it</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
uWSGI mailing list<br>
<a href="mailto:uWSGI@lists.unbit.it">uWSGI@lists.unbit.it</a><br>
<a href="http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi" target="_blank">http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Clemens Kolbitsch</div><div>Security Researcher</div><div><a href="mailto:kolbitsch@lastline.com" target="_blank">kolbitsch@lastline.com</a></div>

<div>Mobile +1 (206) 356-7745</div><div>Land +1 (805) 456-7076<br></div><div><br></div><div>Lastline, Inc.</div><div>6950 Hollister Avenue, Suite 101</div><div>Goleta, CA 93117</div><div><br></div><div><a href="http://www.lastline.com" target="_blank">www.lastline.com</a></div>

</div>
</div>