How to Resolve "systemctl error: Failed to start service, Unit not found"

You try to start, enable, or check a service with systemctl, and instead of managing it, systemd tells you it has no idea what you're referring to. This means systemd's unit file index doesn't contain anything matching the name you gave it — usually because the file is missing, misnamed, or systemd hasn't been told to look for it yet.

The Problem

Running a normal service command fails immediately:

$ sudo systemctl start myapp
Failed to start myapp.service: Unit myapp.service not found.

Checking the status gives the same result:

$ systemctl status myapp
Unit myapp.service could not be found.

Why It Happens

systemd maintains an internal cache of unit files it discovered at the last reload, built from a fixed set of directories. "Unit not found" appears when the exact filename you're referencing isn't present in that cache. Common causes:

• The unit file was created or edited but systemctl daemon-reload was never run afterward, so systemd is still working from its old cached list.
• The file is in the wrong directory — custom services belong in /etc/systemd/system/, not /usr/lib/systemd/system/ (reserved for package-installed units) or some arbitrary location.
• The filename doesn't end in .service (or the correct unit type suffix), which systemd requires to recognize it as a valid unit.
• A typo in the service name when running the command — myapp vs my-app vs myApp are all different unit names to systemd.
• File permissions prevent systemd from reading the unit file at all, which can produce the same "not found" result rather than a permissions error.

The Fix

First, confirm the unit file actually exists where systemd expects it:

ls -la /etc/systemd/system/myapp.service

If it's missing, create it there directly (this is the standard location for custom, non-package services):

sudo nano /etc/systemd/system/myapp.service

[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/usr/local/bin/myapp
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

After creating or editing any unit file, always reload systemd's cache — this step is the single most commonly forgotten fix for this exact error:

sudo systemctl daemon-reload

Now start the service:

sudo systemctl start myapp

Enable it to start automatically on boot if that's the goal:

sudo systemctl enable myapp

If you're not sure of the exact registered name, list all available units and grep for something close to what you expect:

systemctl list-unit-files | grep -i myapp

Still Not Working?

If daemon-reload doesn't help and the file is in the right place with the right name, check the file's permissions — systemd needs to be able to read it, and an overly restrictive mode can cause it to be silently skipped during the unit file scan:

chmod 644 /etc/systemd/system/myapp.service

Also verify there's no syntax error preventing systemd from parsing the file correctly, since a malformed unit file can sometimes be reported as "not found" rather than as a parse error depending on the systemd version:

systemd-analyze verify myapp.service

This command reports specific syntax problems in the unit file directly, which is more actionable than the generic "not found" message if the real issue is a malformed [Service] or [Unit] section.

It's also worth understanding the three main directories systemd scans and what each one is actually meant for, since mixing them up is a frequent source of confusion beyond just this error. /etc/systemd/system/ is for local, host-specific configuration and custom services you write yourself — this is almost always where your unit file should live. /usr/lib/systemd/system/ (sometimes /lib/systemd/system/ depending on the distro) holds unit files installed by system packages via apt or yum, and editing files there directly is discouraged since a package update can silently overwrite your changes. /run/systemd/system/ is for units generated at runtime and doesn't persist across reboots, which makes it the wrong place for anything you want to survive a restart.

If you do need to modify a package-provided service's behavior without touching the original file directly, use a drop-in override instead of editing the file in /usr/lib:

sudo systemctl edit nginx

This opens an editor for a small override file stored separately in /etc/systemd/system/nginx.service.d/, letting you customize specific settings while leaving the original package-managed unit file untouched and safe from being silently overwritten on the next update.