dux2
dux2

Reputation: 1910

nginx - ungraceful worker termination after timeout

I plan to use nginx for proxying websockets. When performing nginx reload / HUP , I understand that nginx waits for the old worker processes to stop processing all requests. In websocket connection however, this may not happen for long time as the connection is persistent. Is there an option / roadmap to forceibly kill old worker process after timeout on reload?

References:

http://nginx.org/en/docs/control.html

http://forum.nginx.org/read.php?21,247573,247651#msg-247651

Thanks

Upvotes: 4

Views: 2963

Answers (1)

Anatoly
Anatoly

Reputation: 15530

Unless you have either solution: proxy_read_timeout 1d or a ping message to keep connection alive, Nginx closes connections in 60sec otherwise. This default value was chosen by a reason.

See what Nginx core developer says:

There is proxy_read_timeout (http://nginx.org/r/proxy_read_timeout) which as well applies to WebSocket connections. You have to bump it if your backend do not send anything for a long time. Alternatively, you may configure your backend to send websocket ping frames periodically to reset the timeout (and check if the connection is still alive).

Having said that nothing should stop you from using USR2+QUIT signals combination that usually used when you gracefully restart Nginx while binary upgrade. Nginx master/worker processes rare consume more than 50MB of memory, so to keep multiple masters isn't that expensive. USR2 helps to fork new master and spawn its workers followed by gracefully shutdown old workers and master.

Upvotes: 3

Related Questions