Open Flid opened 6 years ago
Faced with the same issue. Python 2.7.12 + uwsgi 2.0.17 + Flask 0.10.1
that's actually works fine with --socket= (not --http=) which is OK for us
This is definitely still an issue. It seems like the http router gets buried before the workers finish shutting down.
When I remove shutdown of the gateways from gracefully_kill_them_all
, everything behaves as expected, so it definitely looks like this is the issue.
I think a sensible solution would be to delay the gateway shutdown until all workers are shut down during a graceful shutdown / restart.
I reproduced by making an application (serving requests using --http
) that sleeps for a few seconds (shorter than harakiri) and using gracefully_kill_them_all
while it is handling a request to shut it down.
Without removing gateway shutdown, I get an empty result. When removing gateway shutdown, I get my result body.
I would love a way to fully drain the listen queue before shutting down, but it would be cool if we could finish in-flight requests at least.
Faced this as well recently. This behavior makes graceful shutdown kind of useless for http sockets.
We're also suffering from the same issue, using uWSGI 2.0.18. We'd really like to keep using the --http
option but it does seem like graceful shutdown simply doesn't work in that case.
Maybe it will be useful to someone. Faced the same issue, and with --http
graceful shutdown does not work, even if uwsgi waits for the workers, it stops the additional http
process with its connections first. However, with http-socket
(when uwsgi does not start the additional http process) and --hook-master-start "unix_signal:15 gracefully_kill_them_all"
it works. And if you need HTTP keepalive you can use http11-socket
.
https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
The http and http-socket options are entirely different beasts. The first one spawns an additional process forwarding requests to a series of workers (think about it as a form of shield, at the same level of apache or nginx), while the second one sets workers to natively speak the http protocol. TL/DR: if you plan to expose uWSGI directly to the public, use --http, if you want to proxy it behind a webserver speaking http with backends, use --http-socket.
I'm having the same issue, but with --attach-daemon2
; Does anybody know how to make that work in that scenario? unix_signal:15 gracefully_kill_them_all
just doesn't respect my daemon at some point and brutally kills it...
I have an application with a heavy endpoint, taking 10 seconds to respond. If I shutdown the service (SIGHUP, or SIGTERM with --hook-master-start "unix_signal:15 gracefully_kill_them_all", or sending 'q' to master pipe) - the graceful shutdown sort of works, it really waits for the request to finish. The only problem - it closes client connection right after receiving the command, so I see
curl: (52) Empty reply from server
on client side. After that the worker finishes request processing, writes success message in logs and exits. So the log looks like that (with some comments):I really can't explain this behaviour. Any ideas?
Config file:
And I start it like that:
uwsgi --ini uwsgi.ini --hook-master-start "unix_signal:15 gracefully_kill_them_all"
The application inside is python
flask
withgevent
. I tried with and without gevent - nothing changes.