A failed systemd unit

A failed unit is a single systemd service that exited with an error, not a sign that the whole server is down. Other services can keep running while you identify the bad unit, read its logs, correct the config or path, clear the failed state, and start it again. Begin with the failed list rather than a reboot or a full reinstall, because a reboot often fails the same unit on the way up.

systemctl –failed –no-pager

An empty list usually means you are checking the wrong machine or namespace, the unit was already reset, or the process is running in a crash loop without staying marked failed. When a name appears in the list, pass that name to systemctl status and to journalctl -u. Read both before you edit anything. The message is often “no such file,” “address already in use,” or a dependency that failed first.

Read status and the journal before you edit

Status shows the last exit code and the unit file path. The journal shows the lines that led to the failure. Fix the config, binary path, permissions, or port conflict that the log points to. Common causes include a missing mount, a wrong document root, a leftover process holding a port, or a volume that never came up after boot.

On a VPS you manage yourself, systemd is the right tool for daemons you installed. On cPanel accounts, prefer the panel’s service tools for services the panel owns so you do not fight its own monitors. Use ss -lptn when the log says a port is already in use; that often points to leftover Apache after a move to LiteSpeed, or another process bound to 80 or 443.

Mount order and enable versus start

A unit that needs a filesystem will fail if that mount is missing from fstab, or if the unit starts before the mount is ready. Use After= and Requires=, and treat the related .mount unit as a real dependency. Starting a web server before /var/www is mounted looks like a missing docroot when the real issue is boot order.

Running enable without start leaves a surprise for the next reboot. Running start without enable works until reboot, then the service is gone again. Use both when you want the service permanent. Use neither while you are still testing a config change.

Clear the failed state and start cleanly

After you fix the underlying problem, run systemctl reset-failed so monitoring stops treating the unit as red. That command only clears the failed flag; it does not start the service. Start the unit next, then check status again. If it fails a second time, stay in the journal rather than reaching for a new OS image.

For database or other data services that failed at boot, confirm mounts and disk paths before you start them again. A volume that did not mount can leave an empty data directory, which makes a second start look like a fresh install. Check mounts first, then start the daemon once the path is real.