# Graceful backend shutdown **URL:** \ **Category:** NGINX\ **Created:** [October 7, 2013, 10:08am UTC](https://www.ruby-forum.com/t/graceful-backend-shutdown/236839 "2013-10-07T10:08:48Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![alcina](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/a587f6/32.png) [@alcina](https://www.ruby-forum.com/u/alcina)\ **Post date:** [October 7, 2013, 10:08am UTC](https://www.ruby-forum.com/t/graceful-backend-shutdown/236839/1 "2013-10-07T10:08:48Z")
Hi all! I’m using Nginx as a reverse proxy and loadbalancer with 2 backends. Sometimes I need to turn off one of the apps server. And I need to do it gracefully, that when I comment one server in Nginx config, Nginx master process starts to send new requests to new server, but old requests and sessions stay in old server. I tried to use down, but it loses sessions. Then tried use kill -HUP, but Nginx immediately loads new config and closes old sessions and redirects them to new server. Thanks for help. ---
**Author:** ![aivaras](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@aivaras](https://www.ruby-forum.com/u/aivaras)\ **Post date:** [October 7, 2013, 1:13pm UTC](https://www.ruby-forum.com/t/graceful-backend-shutdown/236839/2 "2013-10-07T13:13:22Z")
Hello! On Mon, Oct 07, 2013 at 10:08:48AM +0200, Aivaras La wrote: > Hi all! > > I’m using Nginx as a reverse proxy and loadbalancer with 2 backends. > Sometimes I need to turn off one of the apps server. And I need to do it > gracefully, that when I comment one server in Nginx config, Nginx master > process starts to send new requests to new server, but old requests and > sessions stay in old server. I tried to use down, but it loses sessions. > Then tried use kill -HUP, but Nginx immediately loads new config and > closes old sessions and redirects them to new server. Thanks for help. On kill -HUP nginx does a gracefull shutdown of old worker processes. That is, all requests being handled by old worker processes are continue to work till they are complete. No requests are lost and/or unexpectedly terminated. Details on reconfiguration process can be found here: [http://nginx.org/en/docs/control.html#reconfiguration](http://nginx.org/en/docs/control.html#reconfiguration) – Maxim D. [http://nginx.org/en/donation.html](http://nginx.org/en/donation.html) ---
**Author:** ![aivaras](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@aivaras](https://www.ruby-forum.com/u/aivaras)\ **Post date:** [October 8, 2013, 10:33am UTC](https://www.ruby-forum.com/t/graceful-backend-shutdown/236839/3 "2013-10-08T10:33:38Z")
Maxim D. wrote in post #1123727: > Hello! > > On Mon, Oct 07, 2013 at 10:08:48AM +0200, Aivaras La wrote: > > > Hi all! > > > > I’m using Nginx as a reverse proxy and loadbalancer with 2 backends. > > Sometimes I need to turn off one of the apps server. And I need to do it > > gracefully, that when I comment one server in Nginx config, Nginx master > > process starts to send new requests to new server, but old requests and > > sessions stay in old server. I tried to use down, but it loses sessions. > > Then tried use kill -HUP, but Nginx immediately loads new config and > > closes old sessions and redirects them to new server. Thanks for help. > > On kill -HUP nginx does a gracefull shutdown of old worker > processes. That is, all requests being handled by old worker > processes are continue to work till they are complete. No > requests are lost and/or unexpectedly terminated. Details on > reconfiguration process can be found here: > > [Controlling nginx](http://nginx.org/en/docs/control.html#reconfiguration) > > – > Maxim D. > [nginx: donation](http://nginx.org/en/donation.html) I’ll try to explain my example: In my config I have upstream with 1 backend, then I change that 1 backend server IP address ( I put something I don’t need (just for example) like local news page). Then I try to access Nginx (with old config) which starts to load my big page. When page is loading I did HUP signal and then my page wasn’t completed. New workers spawned and old workers quitted at the same second. Nobody was waiting. Is there a possibility that old workers wait much longer? Or somehow to change backend servers with serving old sessions? Thanks for help! ---
**Author:** ![aivaras](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@aivaras](https://www.ruby-forum.com/u/aivaras)\ **Post date:** [October 8, 2013, 2:38pm UTC](https://www.ruby-forum.com/t/graceful-backend-shutdown/236839/4 "2013-10-08T14:38:46Z")
Hello! On Tue, Oct 08, 2013 at 10:33:38AM +0200, Aivaras La wrote: > > > process starts to send new requests to new server, but old requests and > > > [Controlling nginx](http://nginx.org/en/docs/control.html#reconfiguration) > > I’ll try to explain my example: > In my config I have upstream with 1 backend, then I change that 1 > backend server IP address ( I put something I don’t need (just for > example) like local news page). Then I try to access Nginx (with old > config) which starts to load my big page. When page is loading I did HUP > signal and then my page wasn’t completed. New workers spawned and old > workers quitted at the same second. Nobody was waiting. Is there a > possibility that old workers wait much longer? Or somehow to change > backend servers with serving old sessions? Thanks for help! From your description of the problem I tend to think that by “loading a big page” you mean a page with many external resources (like images, etc.), and your new nginx configuration isn’t able to handle requests to these resources. This is not going to work. As you probably heard before, HTTP is a stateless protocol. This means that in terms of HTTP there is no such a thing as a “session”, or “page loading”. The only thing HTTP knows about is a _request_. That is, nginx guarantees that _requests_ are handled correctly according to a configuration it has. But nginx doesn’t know that your browser didn’t loaded some of the external resources it needs yet, and your new configuration can’t handle requests to these resources. Correct approach to your problem is to use a configuration that can handle requests all the time, instead of breaking it at some point. – Maxim D. [http://nginx.org/en/donation.html](http://nginx.org/en/donation.html)