Troubleshoot “nginx.service failed because the control process exited”

The systemd message reports that a service command failed; it does not identify the cause. Start with the underlying diagnostic and the command the unit actually runs.

sudo systemctl status nginx --no-pager -l
sudo journalctl -u nginx.service -b -n 100 --no-pager
systemctl cat nginx

The failure may be in a pre-start configuration check or the main startup command. Match the binary, configuration path, prefix, and global options when testing manually.

Validate the configuration

sudo nginx -t

For the default instance this checks syntax and access to referenced files. If the service uses custom options, repeat them. Read the filename and line number in errors such as a missing semicolon, unmatched brace, or directive placed in the wrong context.

Also inspect the Nginx error log if it was successfully opened:

sudo tail -50 /var/log/nginx/error.log

Very early startup failures may exist only in the journal or standard error.

Find who owns the listening ports

A passing configuration test does not guarantee that startup can bind the configured sockets. On Linux:

sudo ss -ltnp '( sport = :80 or sport = :443 )'

The owner may be another web server, another Nginx instance, or an application. Identify why it is running before stopping it or changing a listener. Do not broadly kill every Nginx process: a manually started instance may be serving production traffic.

Check files and runtime paths

Verify certificate and key paths, log-directory existence, explicit include files, and permissions under the unit's security settings. Nginx does not create arbitrary missing parent directories for logs. A missing explicit include differs from a wildcard that matches no files.

If an unmanaged master owns the port, inspect its command and PID and arrange a controlled handover. Once you have confirmed the correct process and impact, a graceful quit targets that master rather than every Nginx process:

# Replace the PID only after identifying the intended master.
sudo kill -QUIT 1234

Wait for the listener to be released before starting the service. Preserve the working configuration and rollback path during the handover.

Start and verify the repaired service

sudo nginx -t && sudo systemctl start nginx
sudo systemctl status nginx --no-pager

Then request the intended hostname and inspect recent logs. “Active” alone does not prove the correct virtual host or application works. Guance HTTP synthetic tests can check the actual endpoint after recovery; configure its assertions and alert policy separately.

FAQ

Why does nginx -t pass while startup fails?

The startup may encounter a port conflict, runtime resource problem, unit restriction, or different startup options. Compare the tested command with ExecStart and inspect the actual failure.

Can I run Nginx in the foreground to see errors?

Yes, in an isolated diagnostic setting, using the correct configuration and daemon off;. First ensure you are not starting a second instance against production listeners or conflicting PID files. The service journal is usually the safer first place to inspect.

Can SELinux prevent startup on a custom port?

Yes. Inspect audit denials and existing port labels. For an intended HTTP listener, a new mapping can use semanage port -a -t http_port_t -p tcp 8081; use the appropriate modification workflow if that port already has a mapping. Do not relabel a port owned by another service without checking the impact.

References: Nginx command-line checks, master-process signals, SELinux nonstandard configurations.