Managing Nginx Service

1. Starting Nginx

Command	Description	Notes
sudo systemctl start nginx	Starts the Nginx service	Service must be enabled to start on boot
sudo systemctl stop nginx	Stops the Nginx service	Gracefully stops all running processes
sudo systemctl restart nginx	Restarts the Nginx service	Reloads configuration and restarts
sudo systemctl status nginx	Checks the status of Nginx service	Shows if service is active or inactive
sudo nginx -t	Tests Nginx configuration syntax	Does not start the service, only validates config

Example: Starting Nginx service

sudo systemctl start nginx
sudo systemctl status nginx

Note: Ensure Nginx is installed and the configuration file is valid before starting.

2. Stopping Nginx

Command	Description	Notes
sudo systemctl stop nginx	Stops the Nginx service immediately	Does not restart automatically
sudo systemctl kill nginx	Kills the Nginx process using SIGTERM	Graceful shutdown with timeout
sudo nginx -s stop	Stops Nginx gracefully using the main process	Requires Nginx to be running
sudo nginx -s quit	Stops Nginx gracefully, waits for connections to finish	Same as stop but with connection handling

Example: Stopping Nginx via systemctl

sudo systemctl stop nginx

Note: Using systemctl stop is preferred for managing Nginx as a service on modern Linux distributions.

3. Reloading Configuration

Reloading Nginx configuration allows applying changes without stopping the server. This is done using the reload command or signal.

Action	Command	Description
Reload via systemctl	`sudo systemctl reload nginx`	Gracefully reloads the Nginx configuration using systemd.
Reload via nginx binary	`sudo nginx -s reload`	Signals the master process to reload configuration files.
Signal	`SIGUSR1`	Send the USR1 signal to the Nginx master process PID.

Example: Reloading Nginx Configuration

sudo nginx -s reload

Note: If the configuration contains syntax errors, Nginx will not reload and will continue serving the previous working configuration.

Warning: Reloading does not restart the Nginx process, so any new modules or changes to the main context (e.g., worker_processes) will not take effect until a full restart.

4. Testing Configuration

Example: Test Nginx Configuration

nginx -t

Command	Description	Output
nginx -t	Test the Nginx configuration file for syntax errors	Displays "test is successful" or error details
nginx -T	Display the full effective configuration (including includes)	Shows merged config in readable format

Note: The -t flag checks the syntax and tests the configuration without actually reloading Nginx.

Warning: If configuration errors are found, Nginx will not reload and may continue running with the old config.

5. Checking Service Status

Command	Description	Notes
systemctl status nginx	Check the current status of the Nginx service	Shows if the service is running, active, and any recent logs
nginx -t	Test the Nginx configuration for syntax errors	Does not start or reload the service, only validates config
systemctl is-active nginx	Check if Nginx is currently active (running)	Returns "active" or "inactive" without detailed logs
systemctl is-enabled nginx	Check if Nginx is enabled to start at boot	Returns "enabled" or "disabled" status for startup

Example: Check Nginx service status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2026-01-01 10:00:00 UTC; 5min ago
     Docs: man:nginx(8)
   Main PID: 12345 (nginx)
      Tasks: 2 (limit: 4915)
     Memory: 12.3M
     CGroup: /system.slice/nginx.service
           ├─12345 nginx: master process /usr/sbin/nginx
           └─12346 nginx: worker process

Jan 01 10:00:00 server systemd[1]: Started A high performance web server and a reverse proxy server.

Example: Test Nginx configuration

$ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

6. Viewing Running Processes

Process	Description	Command
nginx master process	Primary Nginx process that manages worker processes	`ps aux \| grep nginx`
nginx worker processes	Child processes handling client requests	`ps aux \| grep nginx`

Example: Check Nginx Process Status

ps aux | grep nginx

Note: The master process typically runs as root, while worker processes run under the nginx user.

7. Sending Signals

Signal	Description	Command	Usage
SIGTERM	Graceful shutdown of Nginx	`kill -TERM <nginx_pid>`	Stops Nginx after finishing current requests
SIGINT	Immediate shutdown of Nginx	`kill -INT <nginx_pid>`	Kills Nginx immediately, no graceful shutdown
SIGHUP	Reload configuration and reopen log files	`kill -HUP <nginx_pid>`	Re-reads config file without stopping Nginx
SIGUSR1	Reopen log files (rotate logs)	`kill -USR1 <nginx_pid>`	Allows log rotation without restarting Nginx
SIGUSR2	Upgrade Nginx binary (hot upgrade)	`kill -USR2 <nginx_pid>`	Starts new Nginx process with updated binary
SIGWINCH	Graceful shutdown of worker processes	`kill -WINCH <nginx_pid>`	Stops worker processes gracefully

Example: Reload Nginx Configuration

# Find the master process PID
ps aux | grep nginx

# Send HUP signal to reload config
kill -HUP &lt;master_pid&gt;

# Or use nginx command
nginx -s reload

Note: The nginx -s command is a convenient way to send signals. For example, nginx -s reload sends the HUP signal to the master process.

8. Performing Graceful Shutdown

Graceful shutdown allows Nginx to finish processing existing requests before stopping. This is essential for maintaining service availability and preventing data loss.

Command	Description	Notes
nginx -s quit	Initiates graceful shutdown	Stops accepting new connections and waits for existing requests to complete
nginx -s stop	Immediate shutdown	Does not wait for existing requests to complete; terminates immediately

Example: Graceful shutdown using signal

# Send quit signal to Nginx process
kill -QUIT $(cat /var/run/nginx.pid)

# Or use nginx command
nginx -s quit

Note: The -s quit signal allows Nginx to finish serving current requests before shutting down. This is preferred over -s stop in production environments where data integrity is critical.

Warning: Using -s stop or KILL signal will terminate Nginx immediately, potentially dropping ongoing requests.

Shutdown Process Overview

Nginx receives the shutdown signal
Master process stops accepting new connections
Worker processes finish handling current requests
Master process exits once all workers are done

9. Reopening Log Files

Reopening log files allows Nginx to close and reopen its log files, which is useful for log rotation without restarting the server.

Directive	Values	Description
open_log_file_cache	`off`, `on`	Controls the caching of open log files. Default is `off`.

Example: Reopening Log Files

sudo kill -USR1 $(cat /var/run/nginx.pid)

Note: The USR1 signal instructs Nginx to reopen its log files. This is commonly used in log rotation scripts.

10. Understanding Master and Worker Processes

Process Type	Description	Role in Nginx	Configuration
master process	Primary Nginx process that reads configuration and manages worker processes	Controls the entire Nginx instance	Started by default; can be disabled with `master_process off;`
worker process	Handles client requests and connections	Processes incoming HTTP requests, serves static content, forwards proxy requests	Number controlled by `worker_processes` directive

Example: Master and Worker Process Configuration

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    server {
        listen 80;
        server_name example.com;

        location / {
            root /var/www/html;
            index index.html;
        }
    }
}

Key Points About Nginx Processes

Master process reads config and spawns worker processes
Worker processes handle actual client requests
Each worker process is single-threaded but can handle multiple connections
Number of workers should typically match CPU cores or be set to auto
Master process can be disabled for testing or embedded use cases

Note: The master process does not handle client requests directly, it only manages the worker processes and reloads configuration when needed.

11. Upgrading Without Downtime

Upgrade Process

Prepare the new Nginx binary (e.g., download and verify checksums)
Test the new configuration with nginx -t
Signal the running Nginx process to start a new master process with nginx -s reload
Wait for the new master to start and handle new connections
Gracefully shut down old worker processes (they will exit once current requests complete)

Command	Description	Notes
nginx -s reload	Reloads the configuration and starts a new master process	Does not interrupt existing connections
nginx -t	Tests the configuration file for syntax errors	Use before applying changes to avoid downtime

Note: Ensure that the new Nginx binary is compatible with the existing configuration and modules.

Example: Performing a Zero-Downtime Reload

nginx -t
# Output: the configuration file /etc/nginx/nginx.conf syntax is ok
#         the configuration file /etc/nginx/nginx.conf test is successful

nginx -s reload
# Output: Nginx master process starts new worker processes and gracefully shuts down old ones

12. Managing Multiple Nginx Instances

Example: Running Multiple Nginx Instances with Different Configs

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx-instance1.conf
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx-instance2.conf

# Modify instance1 config to use different port
sudo sed -i 's/listen 80;/listen 8080;/' /etc/nginx/nginx-instance1.conf

# Modify instance2 config to use different port
sudo sed -i 's/listen 80;/listen 8081;/' /etc/nginx/nginx-instance2.conf

# Start instances
sudo nginx -c /etc/nginx/nginx-instance1.conf
sudo nginx -c /etc/nginx/nginx-instance2.conf

Instance	Config File	Port	Status
Instance 1	`/etc/nginx/nginx-instance1.conf`	`8080`	Running
Instance 2	`/etc/nginx/nginx-instance2.conf`	`8081`	Running

Note: Ensure each instance uses a unique port and configuration file to avoid conflicts.

Warning: Make sure to manage process IDs properly if using init scripts or systemd services for each instance.