Hosting

How to upgrade NGINX without losing connections?

upgrading NGINX could be a big issue for many users, but not after reading this subject. On the upcoming lines, we will guide you to upgrade NGINX in place, without losing client connections in minutes.

NGINX is one of the most famous web servers that is used to serve many popular sites in the world. It’s open-source software for web serving, reverse proxying, caching, load balancing, media streaming, and more.

How to upgrade NGINX without dropping connections?

Before beginning, you should have a non-root user on your server, configured with Sudo privileges. You will also need to have Nginx installed.

Finding Nginx Process PIDs

In order to send signals to the various processes, we need to know the PID for the target process. There are two easy ways to find this.

  • First, you can use the ps utility and then grep for Nginx among the results. This is simple and allows you to see the master and worker processes:
$ ps aux | grep nginx
output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
user     10961  0.0  0.0 112640   964 pts/0    S+   13:53   0:00 grep --color=auto nginx
  • Another way to find the PID for the master Nginx process is to print out the contents of the /run/nginx.pid file:
$ cat /run/nginx.pid
output
10846

If there are two Nginx master processes running, the old one will be moved to /run/nginx.pid.oldbin.

Spawn a New Nginx Master/Workers Set

The first step to successfully upgrade NGINX is to actually update your binary.

After the new binary is in place, you can spawn a second set of master/worker processes that use the new executable.

You can do this either by sending the USR2 signal directly to the PID number you queried (make sure to substitute the PID of your own Nginx master process here):

$ sudo kill -s USR2 10846

Or, you can read and substitute the value stored in your PID file directly into the command, like this:

$ sudo kill -s USR2 `cat /run/nginx.pid`

If you check your current processes, you will see that you now have two sets of Nginx master/workers:

$ ps aux | grep nginx
output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    10847  0.0  0.1  47936  1908 ?        S    13:26   0:00 nginx: worker process
root     11003  0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11031  0.0  0.0 112640   960 pts/0    S+   14:01   0:00 grep --color=auto nginx

You can also see that the original /run/nginx.pid file has been moved to /run/nginx.pid.oldbin and the newer master process’s PID has been written to /run/nginx.pid:

$ tail -n +1 /run/nginx.pid*
output
==> /run/nginx.pid <==
11003

==> /run/nginx.pid.oldbin <==
10846

You can now send signals to either of the master processes using the PIDs contained in these files.

At this point, both master/worker sets are operational and capable of serving client requests. The first set is using the original Nginx executable and configuration and the second set is using the newer versions. They can continue to operate side-by-side, but for consistency, we should start to transition to the new set.

Shut Down the First Master’s Workers

Stop the original set’s workers by issuing the WINCH signal to their master process:

$ sudo kill -s WINCH `cat /run/nginx.pid.oldbin`

This will let the new master’s workers handle new client connections alone. The old master process will still be running, but with no workers:

$ ps aux | grep nginx
output
root     10846  0.0  0.3  47564  3280 ?        S    13:26   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
root     11003  0.0  0.3  47564  3132 ?        S    13:56   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx    11004  0.0  0.1  47936  1912 ?        S    13:56   0:00 nginx: worker process
user     11089  0.0  0.0 112640   964 pts/0    R+   14:13   0:00 grep --color=auto nginx

After this step, You should test and audit your system at this point to make sure that there are no signs of problems.

If you experienced no issues with your new set’s workers, you can safely shut down the old master process. To do this, just send the old master the QUIT signal:

sudo kill -s QUIT `cat /run/nginx.pid.oldbin`

The old master process will exit gracefully, leaving only your new set of Nginx master/workers. At this point, you’ve successfully performed an in-place binary update of Nginx without losing client connections.

Tags

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close
Close