systemctl says unit not found even though service file exists

The short version

You copy a .service file into /etc/systemd/system/. You type systemctl start myapp.service. And you get Unit not found. Frustrating, right? I've seen this confuse new admins for an hour.

The fix is simple: run sudo systemctl daemon-reload. Then try again.

That's it. But let's walk through the full steps so you don't miss anything.

Step-by-step fix

Let's say your service file is called myapp.service. You already put it in /etc/systemd/system/. But systemctl doesn't see it.

1. Open a terminal.
2. Run sudo systemctl daemon-reload. After this command, you should see no output. It just returns to the prompt. That's normal. It means systemd scanned its config directories again.
3. Now run systemctl status myapp.service. You should see something like Loaded: loaded (/etc/systemd/system/myapp.service; disabled; vendor preset: disabled). If you still see Loaded: not-found, go back to step 2 and check your file name for typos.
4. Then run sudo systemctl enable myapp.service to enable it on boot.
5. Finally run sudo systemctl start myapp.service.

After step 5, check with systemctl status myapp.service. You should see Active: active (running) in green.

Why does this happen?

When you boot your Linux system, systemd reads all unit files (services, timers, sockets, etc.) from /etc/systemd/system/, /usr/lib/systemd/system/, and /run/systemd/system/. It caches this information in memory. When you add a new file to one of those directories, systemd doesn't know about it until you tell it to re-read.

systemctl daemon-reload tells systemd: "Hey, go check for new or changed unit files." It reloads the entire unit cache. Without this step, systemctl still uses the old cache that doesn't have your new service file.

Think of it like a library catalog. You put a new book on the shelf. But the librarian won't find it in the catalog until you update the catalog. That's daemon-reload.

Less common variations of this issue

Sometimes you run daemon-reload and it still doesn't work. Here are three variations I've seen on real systems.

1. Wrong file permissions

Systemd is picky about file ownership and permissions. The service file must be owned by root:root and have permissions 644 or 640. If you copy it as your regular user, it might have wrong ownership.

Fix: sudo chown root:root /etc/systemd/system/myapp.service and sudo chmod 644 /etc/systemd/system/myapp.service. Then run daemon-reload again.

2. Typo in the [Unit] or [Service] section

I once saw a guy misspell After= as After= (capital A is fine, but missing = is not). systemd silently ignores files with syntax errors. It won't load them at all. Check your file with systemd-analyze verify /etc/systemd/system/myapp.service. This tool points out mistakes.

3. File is in the wrong directory

Some people put the service file in /etc/systemd/system/multi-user.target.wants/. That's a symlink directory for enabled services. It's not where you create new services. Put it directly in /etc/systemd/system/.

Also check if you accidentally used /usr/lib/systemd/system/ — that's fine too. But daemon-reload still applies.

How to prevent this problem

From now on, every time you create or edit a service file, immediately run sudo systemctl daemon-reload. Make it a habit. Do it before you even try starting the service.

Also, use systemd-analyze verify after writing the file. This catches syntax mistakes before you waste time debugging.

"A colleague once spent 20 minutes troubleshooting a 'unit not found' error. Turned out he'd saved the file with a .service.txt extension instead of .service. Hidden files. Check with ls -la."

One last thing: if you're on a system with SELinux enabled (like Red Hat or Fedora), you might need to restore the security context: sudo restorecon -v /etc/systemd/system/myapp.service. This is rare but I've seen it in production.