A service will not start on my VPS: reading systemctl status

When a service fails to start, the answer is in two commands: systemctl status service-name and journalctl -u service-name -n 50 --no-pager. The first says that it failed and with what code; the second shows the last lines the service itself wrote, where the reason is. This works for nginx, Apache, the database, SSH and anything systemd manages. On an unmanaged VPS, diagnosing and fixing it is up to you.

Reading the state

1 Ask for the state. sudo systemctl status nginx (swap in your service’s name). Look for three things: the Active: line (“active (running)” is fine; “failed”, or “activating” repeating itself, is not), the exit code in status=, and the last log lines at the bottom.
2 Read more of the log. sudo journalctl -u nginx -n 50 --no-pager. If the problem began after a boot, add -b to keep only the current boot.
3 Test the configuration with the program’s own tool before restarting: nginx -t, apache2ctl configtest, sshd -t. They name the line and file with the error.
4 Fix and start. sudo systemctl restart nginx. Confirm with systemctl status.
5 Make sure it returns by itself after a reboot. systemctl is-enabled nginx should answer “enabled”; if not, sudo systemctl enable nginx. It is the cause of “the site did not come back after a reboot”, described in common VPS and Cloud errors.

What the messages usually mean

What you read Cause and first step
Address already in use / bind() failed Another program holds the port. sudo ss -tlnp | grep :80 shows who. Stop that one, or move one of them to another port.
status=203/EXEC systemd could not run the program: the path in ExecStart is wrong, or the file is not executable. Use the full path.
Permission denied The service user cannot read a file or folder, or cannot write its log. See file permissions; on AlmaLinux or Rocky it may be SELinux: SELinux and AppArmor.
Syntax error / unknown directive A mistake in a configuration file. The message carries the file and the line.
Killed / code=killed, signal=KILL Almost always out of memory: the OOM killer.
No space left on device Disk or inodes full: what fills the disk.
start-limit-hit / Start request repeated too quickly systemd gave up after repeated failures. Fix the cause, then sudo systemctl reset-failed name.
Dependency failed A service this one depends on failed. Look at that one first (systemctl --failed lists them all).
Do not repeat restart blindly. Each failed attempt counts towards systemd’s limit and ends in a “start-limit-hit” that buries the original cause under repeats. Read the first error in the log, not the last.
Edited a systemd service file? You must run sudo systemctl daemon-reload for systemd to reread it. Without it, restart uses the old version.
If you lost SSH and cannot see any of this, the panel console gets you in without the network: I have lost SSH access to my server.

Server not answering even in the panel console? That is on our side, and we will look at once.

Open a support ticket

SEE ALSO

Running your own program as a systemd service

Where the logs are on a Linux VPS

Out of memory: the OOM killer

Common VPS and Cloud errors

RECOMMENDED PRODUCT

VPS server with root access

Resources of your own, the OS you choose, reinstall whenever you like. from ₦12.600,00/mo (3-year plan, with coupon)

See plans
  • 0 Users Found This Useful
Was this answer helpful?