On Wed, Jan 30, 2013 at 4:27 PM, Roberto De Ioris <[email protected]> wrote: > > > Are you sure you are not using some old uWSGI version ? > > What you are trying to accomplish works by about 3 years without emperor, > and from 1 year with the Emperor. > > It's not that old, we're not using the ancient version from the repo, but we haven't kept up with the latest ones.
*** Starting uWSGI 1.3 (64bit) on [Wed Jan 30 16:52:00 2013] *** compiled with version: 4.2.4 (Ubuntu 4.2.4-1ubuntu4) on 11 October 2012 13:06:26 os: Linux-2.6.24-29-server #1 SMP Tue Oct 11 15:57:27 UTC 2011 The weird thing is that they *are* gracefully reloaded. On one hand, in the uwsgi log: *** /var/python/<site>/django.wsgi has been touched... grace them all !!! > *** > ...gracefully killing workers... > Gracefully killing worker 1 (pid: 22028)... > Gracefully killing worker 3 (pid: 22030)... > Gracefully killing worker 13 (pid: 1430)... > Gracefully killing worker 17 (pid: 30238)... > Gracefully killing worker 14 (pid: 1402)... > Gracefully killing worker 2 (pid: 22029)... > Gracefully killing worker 37 (pid: 1617)... > Gracefully killing worker 5 (pid: 22032)... > <snip> > binary reloading uWSGI... > chdir() to /etc/uwsgi/sites > closing all non-uwsgi socket fds > 2 (max_fd = 1024)... > found fd 3 mapped to socket 0 (0.0.0.0:7654) > found fd 4 mapped to socket 1 (0.0.0.0:7655) > found fd 5 mapped to socket 2 (0.0.0.0:7656) > running /usr/bin/uwsgi > *** has_emperor mode detected (fd: 6) *** > [uWSGI] getting INI configuration from <site>.ini > *** Starting uWSGI 1.3 (64bit) on [Tue Jan 15 15:34:55 2013] *** > <etc> On the other hand, nginx/error log: 2013/01/15 15:34:55 [error] 21040#0: *339885263 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885289 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21033#0: *339883966 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21040#0: *339885279 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21033#0: *339885252 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21033#0: *339884971 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885305 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885331 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21033#0: *339884872 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21033#0: *339883581 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885338 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885346 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21038#0: *339880629 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21039#0: *339885384 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21039#0: *339885387 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885352 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21039#0: *339885379 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885360 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21041#0: *339885375 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21034#0: *339882722 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21034#0: *339885169 recv() failed (104: > Connection reset by peer) while reading response header from upstream > 2013/01/15 15:34:55 [error] 21034#0: *339883680 recv() failed (104: > Connection reset by peer) while reading response header from upstream So, yeah. It's gracefully reloading, but not quite. Request in flight are interrupted, but new ones are accepted by the new workers instantly without interruptions, there are no errors related to connection refused / or connect() timed out. It's indeed possible to configure uwsgi to reload gracefully, but the point is to figure out why gracefully_kill(0); in loop.c:166 is called correctly, printing "Gracefully killing worker %d (pid: %d)..." in the log, but the other side of the socket gets a "Connection reset by peer." Next time I'm toying with it, I'll move Nginx out of the loop by using ab / jmeter directly on uwsgi and see if they see the same response. Kind regards, Chi Ho Kwok
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
