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
$ cat /run/nginx.pid
If there are two Nginx master processes running, the old one will be moved to
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.