So you want Nginx' latest stable release? But are worried about downtime, having to reboot Nginx or even your Linux server?
Fear not! Here goes …
Assume Super-User (root) Permissions
This just saves a few keystrokes:-
.. and, prompted, provide your password.
Backing up Nginx
It's over-cautious perhaps but, erring on the safe side, backup the existing Nginx configuration and binary files:-
.. if that threw an error, probably your files are located elsewhere. Try this instead:-
.. if that fails, to find out where they are:-
Download Nginx Latest Stable Release
You may already have this directory but if not, create it and go there:-
.. swapping USERNAME for your username.
Now check for the latest stable release or, if you're feeling adventurous, the development release (although there may be a bug or two). Surf to:-
.. scroll down the page and make a note of the version you want which, as of
writing updating this guide in June 2011, is nginx-1.0.4.
To grab the latest stable version, unzip it and go into its new folder, changing the version number as required:-
Configure Nginx .. but with what Modules?
Good question, well asked. Let's consider this.
While you can compile a bog-standard, generic Nginx setup, more likely you'll want to compile the web server with your specific requirements in mind, pulling in specific modules to help, for example, with security or website features.
This is a tutorial unto itself and, guess what, you can check it out here:-
.. and I would recommend that you do 😛
Else, most simply to upgrade with the same modules as before, we can easily find out what we did last time, recompiling as before:-
.. or if, as above, that threw an error, probably your files are located elsewhere. Try this instead:-
You'll see something like this:-
After the top line, where we inputted the command, here's an example of what we have:-
- nginx version the installed Nginx version
- built by gcc the compiler used to build Nginx last time
- configure arguments the variables used when compiling Nginx. Of these:-
- –sbin-path=/usr/local/sbin/nginx you specified this path to the Nginx installation directory
- –with-http_ssl_module you specified to bundle Nginx with just this module. You may have several other, similar looking, modules combined too.
So .. according to the above example (which pretty much you'll have, word for word, if you followed Nginx (better than Apache) Web Server) you installed Nginx with the addition of the HTTPS/SSL secure socket layer module (so people can shop on your sites.) You also specified ‘/usr/local/sbin' as the installation path.
To replicate your original setup use those options shown after your original configure arguments:.
(Or if you want to consider a different Nginx module combination, read the Nginx module tutorial linked above to show you how.)
Replicating as before, using the example above, the options were:-
.. all we have to do now is to tell Ubuntu to compile the package, like this:-
Alternatively, if you never specified an installation path before (in which case you would have encountered those two errors mentioned above) use this instead with the default path:-
As an aside, once the compiler has run, at the bottom of the file are shown a bunch of handy file locations, for error logs, for example, rather like this:-
.. these can be handy for troubleshooting in the future so you may like to take a note of these paths.
Install the Newly Compiled Latest Nginx Version
Replacing a Current Nginx Install Without Downtime
Here's the magic: the meat and potaters that allows us to upgrade without losing any server queries.
We'll send a signal to the original Nginx process identification – or PID – file, starting the new web server process while keeping the old one running as well. Then, after checking the running state of the new PID, we'll end the old process, leaving the new one running in its place.
But. to avoid confusion in a moment, here's a quick detour ..
Find the Old Nginx Process Identification (PID) Number
In a sec we'll have both the original and new Nginx processes working side by side before disabling the former of the two. To ensure we don't mistake one for the other, we'll identify the original now, as it's the only one enabled so far.
To find the PID's process number we use a process command:-
From the list, look for the entries bunched together that look something like:-
.. of those, the top entry is, as it says, the master process. The others are the worker processes. The PID number is shown in the second column so, for my original Nginx PID, that's ‘1051'. Note yours down.
Do this to rename the existing PID and start a secondary process from the new Nginx binary:-
Now we can stop those workers by using the PID for the master process. Mine above was ‘1051', so swap for yours:-
Browse to a web page being served by your VPS. (Didn't resolve properly? See below.) Resolves OK? Then kill the original master process, leaving the new one in its place. With my master's PID I use:-
Finally, quit playing God and leave ‘root':-
Thassit. Try resolving some websites, I'll see you down the pub.
Didn't resolve OK?
If you followed this tutorial with a keen eye then this is unlikely. Probably you have a compilation error. You'll have to try a recompilation and maybe come say “hi!” in the forums.
But first, before recompiling, let's get your sites resolving again with your original Nginx setup and tidy up those PIDs.
Swapping the PID number for yours, do this to reinstate the old process workers:-
Now find the new Nginx process workers by again issuing the process list command:-
You'll see the ps output for Nginx similar to the above except now there are two lots of Nginx processes. You'll work out which is which because you have already noted the original PID number. Now note the new Nginx master process PID number. I'll example ‘123'.
We'll stop the new Nginx master process workers:-
And the new Nginx master process itself:-
With the original Nginx still happily resolving your sites and the new installation having been shut down, now try recompiling anew and check for any errors in the output.
Let me know any problems, but I suspect you'll be OK.