Sometimes systemd does start the program, and the program refuses to work because of its own settings. This step shows what that looks like with nginx.
Before nginx starts, its unit checks the configuration: the ExecStartPre line with nginx -t. If the configuration has an error, the check returns code 1/FAILURE, and nginx does not start. You can run the same check by hand:
On an error, nginx -t prints the file, the line number and what is wrong on it. A fixed configuration is not yet a working site: after the fix nginx has to be started, and the site has to be checked with a request. If nginx is already running, the change is applied with sudo systemctl reload nginx: with an error in the configuration, reload fails with Job for nginx.service failed, and nginx keeps running with the old one.
The request to the site:
The first response line HTTP/1.1 200 OK means the site answers. active in the status is about the process; the site's response is about the service doing its job.
After a configuration fix, sudo nginx -t prints syntax is ok and test is successful, while curl -I http://localhost/ prints Failed to connect to localhost port 80. What do you do?
-
daemon-reloadrereads unit files, but you edited nginx's configuration. nginx will not start from it. -
nginx -tchecked the whole configuration, and it is valid. The site does not answer because nothing is serving it: checksystemctl is-active nginx. -
enablewithout--nowprepares a start at boot, but the site is needed now: nginx has to be running.
A valid configuration is not yet a working site: Failed to connect means nothing listens on port 80. After sudo systemctl start nginx, repeat curl -I and expect HTTP/1.1 200 OK.
Key points
-
An error in a program's settings shows up in the program's own check: for nginx,
sudo nginx -twith the file and line number. -
Recovery is confirmed by a useful result, such as a
200 OKresponse tocurl -I.