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 applications those
that require immediate user input thus running on 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, named the name server daemon, or crond
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, 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 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:
The Nginx master process,
which 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. Additionally, the user directive that allows you to specify a different user and group for the worker processes will not be taken into consideration.
The Nginx worker processes, which are started under the account you specified in the configuration file with the user
directive . The configuration setting takes
precedence over the configure switch you may have entered at compile
time. If you did not specify any of those, the worker processes will be
started as user nobody, and group 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 the
background processes. To get the 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 the log files
|
|
nginx s reload
|
Reloads the configuration
|
Note that when starting the daemon, stopping it, or performing any of the above 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, you cannot 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:
[[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 using a
regular method, 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 or not
it is valid. The screenshot below shows an invalid configuration, and
as a result, a failed test.
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 at all costs. 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 /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.
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 pre-compilation 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";
