Fix "Failed to start X.service: Unit X.service not found."

systemctl list-unit-files --type=service | grep -i nginx
# nothing listed? install the package that provides it, e.g.
sudo apt install nginx        # Ubuntu / Debian / Mint
sudo dnf install nginx        # Fedora
# you wrote the unit file yourself?
sudo systemctl daemon-reload

You see one of these, depending on the command:

Failed to start nginx.service: Unit nginx.service not found.
Failed to restart sshd.service: Unit sshd.service not found.
Unit apache2.service could not be found.
Failed to enable unit: Unit file myapp.service does not exist.

What the error means

systemd looked for a unit file with that exact name in its search paths (mainly /etc/systemd/system/, /run/systemd/system/ and /usr/lib/systemd/system/, or /lib/systemd/system/ on older Debian-family systems) and found nothing. The service did not fail; it does not exist as far as systemd is concerned. A service that exists but crashes gives a different message, covered in Job for X.service failed.

The quickest check is a search that ignores case and partial names:

systemctl list-unit-files --type=service | grep -i ssh

Example output on Ubuntu:

ssh.service                    enabled         enabled
[email protected]                   static          -

That shows the unit is called ssh, not sshd.

Cause 1: the service has a different name on your distro

Tutorials are written for one distribution, and package maintainers name services differently. These are the usual mix-ups:

Names are also case-sensitive: it is NetworkManager, not networkmanager. Some units are aliases that only exist once the service is enabled, so the canonical name from list-unit-files is the reliable one.

Cause 2: the package is not installed

If no similar name is listed, the software is missing, or you installed only the client part. Common examples: openssh-client without openssh-server, the docker.io or Docker CE packages not installed (see installing Docker), or mysql-client without the server. Find the package that ships a unit:

# Ubuntu / Debian (apt-file: sudo apt install apt-file && sudo apt-file update)
apt-file search nginx.service
# Fedora
dnf provides '*/nginx.service'
# Arch
pacman -F nginx.service
# openSUSE
zypper search --provides /usr/lib/systemd/system/nginx.service

To see which units an installed package ships:

dpkg -L openssh-server | grep '\.service'     # Debian family
rpm -ql openssh-server | grep '\.service'     # Fedora, openSUSE
pacman -Ql openssh | grep '\.service'         # Arch

Programs installed as a snap use names like snap.lxd.daemon.service; Flatpak apps and AppImages normally have no system service at all. The package managers guide covers install commands per distro.

Cause 3: you created the unit but systemd has not reloaded

After creating or renaming a unit file, tell systemd to re-read its configuration, then start the unit:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

Also check where and how the file was saved:

• It must be in a unit directory, normally /etc/systemd/system/ for your own units. A file in your home directory or /opt is not found unless you link it with systemctl link, and a linked file on a filesystem that is not mounted at boot disappears.
• The extension must be exactly .service (editors sometimes save myapp.service.txt or leave a ~ backup).
• Check the file with systemd-analyze verify /etc/systemd/system/myapp.service; syntax problems are reported there.

Cause 4: user unit vs system unit

systemd runs a separate manager per logged-in user. Units in ~/.config/systemd/user/ (and packaged user units such as pipewire, wireplumber or syncthing on many distros) belong to the user manager and are invisible to sudo systemctl. The reverse is also true.

# user services: no sudo
systemctl --user status pipewire
systemctl --user daemon-reload
systemctl --user enable --now myjob.service

If systemctl --user fails with "Failed to connect to bus", you are in a session without a user manager (for example after su); see Failed to connect to bus.

Cause 5: template units and old init scripts

Units whose file name contains @, such as [email protected] or [email protected], are templates. You must start an instance by adding a name after the @:

sudo systemctl start wg-quick@wg0
sudo systemctl start openvpn-client@work

Software that only ships a System V script in /etc/init.d/ used to get an automatic unit from systemd's compatibility generator. Recent systemd releases (258 and later) removed that generator, so on current distributions such old scripts no longer appear as units. Write a small native unit for them instead; the systemd basics guide shows a template.

Distro notes

• Ubuntu 24.04+: SSH is socket-activated by default, so you may see ssh.socket active while ssh.service is inactive. Both exist; the service starts on the first connection.
• Debian, Ubuntu: packages usually enable and start their service on install. Fedora, openSUSE, Arch install it disabled, so after installing run sudo systemctl enable --now name.
• WSL and containers: if every unit seems missing and systemctl complains about PID 1, systemd is not running at all; see this page.
• Distros without systemd (Alpine, Devuan, Void, Gentoo with OpenRC) have no units; use rc-service, service or sv instead.

How to prevent it

• Use systemctl list-unit-files | grep -i name before following a tutorial written for another distro.
• Put your own units in /etc/systemd/system/, run daemon-reload after every change, and check them with systemd-analyze verify.
• Keep the systemctl cheat sheet handy for listing, enabling and inspecting units.

Frequently asked questions