"Job for nginx.service failed because the control process exited with error code": how to find the cause

1. Read the status

systemctl status nginx --no-pager

× nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2026-11-01 09:12:40 UTC; 2min ago

Nov 01 09:12:40 ohsudo systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
Nov 01 09:12:40 ohsudo nginx[702]: nginx: [emerg] unknown directive "servername" in /etc/nginx/sites-enabled/default:5
Nov 01 09:12:40 ohsudo nginx[702]: nginx: configuration file /etc/nginx/nginx.conf test failed
Nov 01 09:12:40 ohsudo systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE

Three things to look at:

• Active: failed (Result: …) — exit-code means a command returned an error; signal means it was killed; start-limit-hit means systemd stopped trying (section 5).
• status=… on the “exited” line — the exit code. Codes above 200 come from systemd itself and have names (section 4).
• The lines from the service itself (here nginx[702]: …) — usually the real error, in the program’s own words.

systemctl status shows only the last few lines. If they are cut, or you need more, read the journal.

2. Read the journal

sudo journalctl -xeu nginx --no-pager

-u nginx limits it to this unit, -e jumps to the end, and -x adds explanations to systemd’s messages. Read from the bottom up to the first line that comes from the program, not from systemd[1]. With --since "10 min ago" you can skip older starts.

Some services also write to their own log file, and the most useful message may be only there: /var/log/nginx/error.log, /var/log/apache2/error.log (/var/log/httpd/ on RHEL), /var/log/postgresql/.

3. Test the configuration

Most of the time, the error is a typo in a config file someone just edited. Most daemons can check their own configuration without starting, and they tell you the file and the line:

sudo nginx -t

nginx: [emerg] unknown directive "servername" in /etc/nginx/sites-enabled/default:5
nginx: configuration file /etc/nginx/nginx.conf test failed

Fix the line, test again, and start the service only when the test passes:

sudo sed -i 's/servername/server_name/' /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl start nginx

The same idea for other services:

4. The usual causes

The port is taken. bind() to 0.0.0.0:80 failed (98: Address already in use) — another program already listens there. See find who is using port 80.

A file is missing or can’t be read. A certificate, a key, a log folder, a socket path:

nginx: [emerg] cannot load certificate "/etc/ssl/certs/example.com.crt": BIO_new_file() failed (… No such file or directory …)

Check the path from the message with ls -l, and check that the service’s user can read it. On RHEL-family systems, a file with the wrong SELinux label gives Permission denied even with correct permissions: sudo restorecon -v <file>.

The program can’t be started at all. For your own services, the exit status has a name that tells you which step failed:

You edited the unit file but systemd still uses the old one. systemd warns you about it:

Warning: The unit file, source configuration file or drop-ins of myapp.service changed on disk. Run 'systemctl daemon-reload' to reload units.

Run sudo systemctl daemon-reload, then start the service again.

5. “Start request repeated too quickly”

myapp.service: Start request repeated too quickly.
myapp.service: Failed with result 'start-limit-hit'.

A service that crashes and restarts in a loop is stopped after a few tries (by default, 5 starts in 10 seconds). This isn’t the cause, only a symptom — find the real error further up in the journal. After you fix it, clear the counter and start again:

sudo systemctl reset-failed myapp
sudo systemctl start myapp