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 <[email protected]> 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 <[email protected]>
> > wrote:
> >
> >> lazy option is discouraged.
> >> lazy-app option may help you.
> >>
> >> On Wed, Apr 9, 2014 at 1:06 AM, Clemens Kolbitsch
> >> <[email protected]> wrote:
> >> > On Tue, Apr 8, 2014 at 3:13 AM, Roberto De Ioris <[email protected]>
> >> 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
> >> > [email protected]
> >> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >> >
> >>
> >>
> >>
> >> --
> >> INADA Naoki <[email protected]>
> >> _______________________________________________
> >> uWSGI mailing list
> >> [email protected]
> >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >>
> >
> >
> >
> > --
> > Clemens Kolbitsch
> > Security Researcher
> > [email protected]
> > 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
> > [email protected]
> > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> >
>
>
> --
> Roberto De Ioris
> http://unbit.it
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
--
Clemens Kolbitsch
Security Researcher
[email protected]
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
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
