systemctl: Unit Not Found Error — How to Fix

What the "systemctl: unit not found" Error Means

The error Failed to start unit: Unit not found (or simply Unit <name> not found.) occurs when the systemctl command cannot locate the specified unit (service, timer, socket, etc.) in the directories where systemd searches for configuration files.

Symptoms:

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

Or:

$ sudo systemctl enable nginx
The unit files have no [Install] section. They cannot be enabled.

(The second error is a common "relative," where the file exists but lacks the [Install] section required for enable).

This error does not mean the service is broken. It means systemd does not know about the existence of such a unit at the moment.

Common Causes

1. Incorrect or incomplete unit name. You specified nginx, but systemd looks for nginx.service. Or you misspelled the name (ngnix.service).
2. The service file (.service) is missing from the system. You are trying to manage a service that was never installed or has been removed.
3. The service file exists, but systemd is unaware of it. The .service file is in /etc/systemd/system/ or /usr/lib/systemd/system/, but after creating or copying it, you did not run systemctl daemon-reload.
4. The unit has a different type. You try to start mytimer.timer with systemctl start mytimer (without .timer), and systemd defaults to assuming a .service type.
5. Corrupted or invalid unit file. The file exists but has syntax errors, causing systemd to refuse to load it (often accompanied by a different error, but it can also masquerade as "not found").

Solutions

Solution 1: Verify and Find the Correct Unit Name

This is the first and most crucial step. Systemd is very sensitive to names.

1. Get a full list of all loaded units:

   systemctl list-units --type=service --all
   

   
   The --all flag shows even inactive (stopped) services.
2. Or get a list of all available service files (even those not loaded):

   systemctl list-unit-files --type=service
   

   
   This command shows which services systemd knows about and can manage.
3. Use search if you don't remember the exact name:

   systemctl list-unit-files --type=service | grep -i <part_of_name>
   # Example: search for anything related to nginx
   systemctl list-unit-files --type=service | grep -i nginx
   

   
   The result might be:

   nginx.service                          enabled
   

   
   The correct name for commands is nginx.service.
4. If the service is not in the list — it means systemd does not detect a corresponding .service file in the standard directories (/etc/systemd/system/, /usr/lib/systemd/system/). Proceed to Solution 3.

⚠️ Important: Always use the full name with the extension (.service, .timer, .socket) for clarity, especially in scripts.

Solution 2: Reload systemd Configuration (daemon-reload)

If you just created, copied, or edited a service file (.service), systemd is unaware of these changes until you explicitly tell it to reload configurations.

1. Run the command:

   sudo systemctl daemon-reload
   

   
   This forces the systemd manager to rescan the unit directories and load new/modified configurations.
2. After this, try to start or enable the service again:

   sudo systemctl start <service_name>.service
   sudo systemctl enable <service_name>.service # for autostart
   

Solution 3: Create or Restore the Service File

If, after searching (Solution 1), you did not find the needed service, its file is absent from the system.

1. Determine where the file should reside. Typically:
   • /etc/systemd/system/ — for administrative configurations and custom services.
   • /usr/lib/systemd/system/ — for services shipped with packages (managed by the package manager).
2. Create a basic service file. For example, to start a simple script /opt/myapp/start.sh:

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

   
   Paste a minimal template:

   [Unit]
   Description=My Custom Application
   After=network.target
   
   [Service]
   Type=simple
   ExecStart=/opt/myapp/start.sh
   Restart=on-failure
   
   [Install]
   WantedBy=multi-user.target
   

   
   Save and close the editor.
3. Set correct permissions:

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

4. Reload the daemon (Solution 2) and then enable the service:

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

5. Check the status:

   sudo systemctl status myapp.service
   

Solution 4: Check File Integrity and Syntax

If the service file exists but systemctl stubbornly doesn't see it, there might be a critical syntax error.

1. Check the file for errors:

   sudo systemd-analyze verify /etc/systemd/system/<service_name>.service
   

   
   If the output is empty, the syntax is fine. If there are errors, the command will show the line and description of the problem.
2. Check that the file is not a broken symbolic link:

   ls -l /etc/systemd/system/<service_name>.service
   

   
   Ensure the link (if it's a link) points to an existing file in /usr/lib/systemd/system/.
3. Check file permissions: systemd typically requires service files to be owned by root and have permissions 644 (readable by all, writable by owner).

Prevention

• Always run systemctl daemon-reload after manually creating, copying, or editing any .service, .timer, or .socket files.
• Specify the full unit name (with .service) in scripts and automation to avoid ambiguity.
• Install services via the package manager (apt install nginx, dnf install httpd) whenever possible. Packages automatically place files in the correct directories and perform daemon-reload.
• Verify syntax of a new service file using systemd-analyze verify before attempting to load it.
• Store custom service files in /etc/systemd/system/, not in /usr/lib/systemd/system/, to prevent them from being overwritten during package updates.

# Quick checklist when the error appears:
# 1. systemctl list-unit-files --type=service | grep <name>
# 2. If no file -> create it (Solution 3)
# 3. If file exists -> sudo systemctl daemon-reload
# 4. sudo systemctl start <full_name>.service