Failed to start nginx.service: Unit nginx.service not found. — how to fix
Failed to start nginx.service: Unit nginx.service not found.
Failed to restart myapp.service: Unit myapp.service not found.
Unit docker.service could not be found.
Quick fix: Find the real name with systemctl list-unit-files | grep -i nginx. Install the package if missing (sudo apt install nginx). For your own unit, put it in /etc/systemd/system/myapp.service, then sudo systemctl daemon-reload && sudo systemctl enable --now myapp. In WSL/containers without systemd, use service nginx start or enable systemd.
What it means
systemctl start foo asks systemd for the unit foo.service. systemd only knows units whose files are in its search paths (/etc/systemd/system/, /run/systemd/system/, /lib/systemd/system/ or /usr/lib/systemd/system/) and that it has loaded since the last reload. If none match, you get Unit ... not found.
Search for anything similar:
systemctl list-unit-files | grep -i nginx
systemctl list-units --all | grep -i nginx
Cause 1: the software isn't installed
The unit file comes with the package. Install it:
sudo apt install nginx # Debian/Ubuntu
sudo dnf install nginx # Fedora/RHEL
Check which package owns a unit on Debian/Ubuntu: dpkg -S nginx.service. Software installed from a tarball, pip or npm usually ships no unit at all; you write one (Cause 3).
Cause 2: the service has a different name
Names vary by distro and version:
| You typed | Actual unit (examples) |
|---|---|
mysql |
mysql (Ubuntu), mysqld (RHEL), mariadb |
postgresql |
postgresql (Ubuntu), postgresql-16 (PGDG on RHEL) |
httpd / apache |
apache2 (Debian/Ubuntu), httpd (RHEL) |
ssh |
ssh (Debian/Ubuntu), sshd (RHEL/Arch) |
docker |
docker (docker-ce), snap.docker.dockerd (snap) |
Snap services are named snap.<name>.<app>; list them with snap services.
Cause 3: your own unit file isn't where systemd looks
Create it in /etc/systemd/system/ with a .service extension:
# /etc/systemd/system/myapp.service
[Unit]
Description=My app
After=network.target
[Service]
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python app.py
Restart=on-failure
[Install]
WantedBy=multi-user.target
Then:
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
Files in your home directory, or with the wrong extension (myapp.conf, myapp.service.txt), are ignored. A symlink is fine (sudo systemctl link /path/to/myapp.service).
Cause 4: you forgot daemon-reload
After creating, renaming or editing a unit file, systemd keeps using its old view until:
sudo systemctl daemon-reload
Cause 5: it's a user service, not a system service
Units in ~/.config/systemd/user/ belong to your user manager. Manage them without sudo and with --user:
systemctl --user daemon-reload
systemctl --user start myapp
Running sudo systemctl start myapp looks in the system manager and won't find it (and vice versa).
Cause 6: no systemd (WSL, Docker containers)
Containers normally run without systemd, and older WSL setups too, where you'll see System has not been booted with systemd as init system. Use the SysV wrapper, or start the program directly:
sudo service nginx start
On WSL2 you can enable systemd by adding this to /etc/wsl.conf, then running wsl --shutdown from Windows:
[boot]
systemd=true
In a Docker container, run the process in the foreground as the container's command instead (e.g. CMD ["nginx", "-g", "daemon off;"]).
Last updated 2026-11-01.