Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Nginx HTTP Server

You're reading from   Nginx HTTP Server Harness the power of Nginx to make the most of your infrastructure and serve pages faster than ever before

Arrow left icon
Product type Paperback
Published in Feb 2018
Publisher Packt
ISBN-13 9781788623551
Length 348 pages
Edition 4th Edition
Languages
Tools
Concepts
Arrow right icon
Authors (2):
Arrow left icon
Martin Bjerretoft Fjordvald Martin Bjerretoft Fjordvald
Author Profile Icon Martin Bjerretoft Fjordvald
Martin Bjerretoft Fjordvald
Mr. Clement Nedelcu Mr. Clement Nedelcu
Author Profile Icon Mr. Clement Nedelcu
Mr. Clement Nedelcu
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface 1. Downloading and Installing Nginx 2. Basic Nginx Configuration FREE CHAPTER 3. HTTP Configuration 4. Module Configuration 5. PHP and Python with Nginx 6. Nginx as an Application Server 7. Apache and Nginx Together 8. From Apache to Nginx 9. Introduction to Load Balancing and Optimization 10. Case Studies 11. Troubleshooting 12. Other Books You May Enjoy

Controlling the Nginx service

At this stage, you should have successfully built and installed Nginx. The default location for the output files is /usr/local/nginx, so we will be basing future examples on this.

Daemons and services

The next step is obviously to execute Nginx. However, before doing so, it's important to understand the nature of this application. There are two types of computer application—those that require immediate user input, thus running in the foreground, and those that do not, thus running in the background. Nginx is of the latter type, often referred to as daemon. Daemon names usually come with a trailing d and a couple of examples can be mentioned here—httpd the HTTP server daemon is the name given to Apache under several Linux distributions, named the nameserver daemon, or cron the task scheduler—although, as you will notice, it is not the case for Nginx. When started from the command line, a daemon immediately returns the prompt window, and in most cases, does not even bother outputting data to the terminal.

Consequently, when starting Nginx you will not see any text appear on the screen and the prompt will return immediately. While this might seem startling, it is on the contrary a good sign. It means the daemon was started correctly and the configuration did not contain any errors.

User and group

It is of the utmost importance to understand the process architecture of Nginx and particularly the user and groups its various processes run under. A very common source of troubles when setting up Nginx is invalid file access permissions—due to a user or group misconfiguration, you often end up getting 403 Forbidden HTTP errors because Nginx cannot access the requested files.

There are two levels of processes with possibly different permission sets:

  • Nginx master process: This should be started as root. In most Unix-like systems, processes started with the root account are allowed to open TCP sockets on any port, whereas other users can only open listening sockets on a port above 1024. If you do not start Nginx as root, standard ports such as 80 or 443 will not be accessible.
The user directive that allows you to specify a different user and group for the worker processes will not be taken into consideration for the master process.
  • Nginx worker processes: These are automatically spawned by the master process under the account you specified in the configuration file with the user directive (detailed in Chapter 2Basic Nginx Configuration). The configuration setting takes precedence over the configuration switch you may have specified at compile time. If you did not specify any of those, the worker processes will be started as user nobody, and the group will be nobody (or nogroup depending on your OS).

Nginx command-line switches

The Nginx binary accepts command-line arguments for performing various operations, among which is controlling background processes. To get a full list of commands, you may invoke the help screen using the following commands:

[[email protected] ~]$ cd /usr/local/nginx/sbin
[[email protected] sbin]$ ./nginx -h

The next few sections will describe the purpose of these switches. Some allow you to control the daemon, some let you perform various operations on the application configuration.

Starting and stopping the daemon

You can start Nginx by running the Nginx binary without any switches. If the daemon is already running, a message will show up indicating that a socket is already listening on the specified port:

[emerg]: bind() to 0.0.0.0:80 failed (98: Address already in use) [...] [emerg]: still could not bind().  

Beyond this point, you may control the daemon by stopping it, restarting it, or simply reloading its configuration. Controlling is done by sending signals to the process using the nginx -s command:

Command

Description

nginx -s stop

Stops the daemon immediately (using the TERM signal)

nginx -s quit

Stops the daemon gracefully (using the QUIT signal)

nginx -s reopen

Reopens log files

nginx -s reload

Reloads the configuration

 

When starting the daemon, stopping it, or performing any of the preceding operations, the configuration file is first parsed and verified. If the configuration is invalid, whatever command you have submitted will fail, even when trying to stop the daemon. In other words, in some cases you will not be able to even stop Nginx if the configuration file is invalid.

An alternate way to terminate the process, in desperate cases only, is to use the kill or killall commands with root privileges:

[[email protected] ~]# killall nginx

Testing the configuration

As you can imagine, this tiny bit of detail might become an important issue if you constantly tweak your configuration. The slightest mistake in any of the configuration files can result in a loss of control over the service—you are then unable to stop it via regular init control commands, and obviously, it will refuse to start again.

In consequence, the following command will be useful to you in many occasions. It allows you to check the syntax, validity, and integrity of your configuration:

[[email protected] ~]$ /usr/local/nginx/sbin/nginx -t

The -t switch stands for test configuration. Nginx will parse the configuration anew and let you know whether it is valid or not. A valid configuration file does not necessarily mean Nginx will start though as there might be additional problems such as socket issues, invalid paths, or incorrect access permissions.

Obviously, manipulating your configuration files while your server is in production is a dangerous thing to do and should be avoided when possible. The best practice, in this case, is to place your new configuration into a separate temporary file and run the test on that file. Nginx makes it possible by offering the -c switch:

[[email protected] sbin]$ ./nginx -t -c /home/alex/test.conf

This command will parse /home/alex/test.conf and make sure it is a valid Nginx configuration file. When you are done, after making sure that your new file is valid, proceed to replacing your current configuration file and reload the server configuration:

[[email protected] sbin]$ cp -i /home/alex/test.conf usr/local/nginx/conf/nginx.conf
cp: erase 'nginx.conf' ? yes
[[email protected] sbin]$ ./nginx -s reload

Other switches

Another switch that might come in handy in many situations is -V. Not only does it tell you the current Nginx build version, but more importantly it also reminds you about the arguments that you used during the configuration step – in other words, the command switches that you passed to the configure script before compilation:

[[email protected] sbin]$ ./nginx -V
nginx version: nginx/1.13.8 (Ubuntu)
built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
TLS SNI support enabled
configure arguments: --with-http_ssl_module

In this case, Nginx was configured with the --with-http_ssl_module switch only.

Why is this so important? Well, if you ever try to use a module that was not included with the configure script during the precompilation process, the directive enabling the module will result in a configuration error. Your first reaction will be to wonder where the syntax error comes from. Your second reaction will be to wonder if you even built the module in the first place! Running nginx -V will answer this question.

Additionally, the -g option lets you specify additional configuration directives, in case they were not included in the configuration file:

[[email protected] sbin]$ ./nginx -g "timer_resolution 200ms";
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image