A systemd service file does not have to live in /etc/systemd/system. The system manager searches several directories for unit files, and the directory matters because the search order defines which definition wins when the same unit name exists in more than one place.
For an administrator-managed service, /etc/systemd/system is usually the appropriate location. Distribution packages normally install units under /usr/lib/systemd/system, while /run/systemd/system is used for runtime configuration that disappears after reboot. This separation lets local configuration override vendor defaults without editing files owned by the package manager.
systemd resolves unit names through a search path
When a command refers to a unit by name,
systemctl start myapp.servicesystemd resolves myapp.service through its unit load path. A simplified view of important system-level locations is:
/etc/systemd/system
/run/systemd/system
/usr/local/lib/systemd/system
/usr/lib/systemd/systemThe complete load path contains additional directories for generated, transient, and attached units. The important property is precedence: a unit found earlier in the search path overrides a unit with the same name found later.
That means these two files are not combined as two independent services:
/etc/systemd/system/myapp.service
/usr/lib/systemd/system/myapp.serviceThe definition in /etc/systemd/system/myapp.service takes precedence.
The effective search path can be inspected directly:
systemd-analyze unit-pathsThis is more reliable than assuming every distribution uses exactly the same filesystem layout.
/etc/systemd/system is for local administrator configuration
A custom service created directly by a system administrator normally belongs in:
/etc/systemd/system/myapp.serviceFor example:
[Unit]
Description=My application
After=network.target
[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/server
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.targetOnly the unit definition needs to be in the systemd search path. The application itself does not.
The executable can live elsewhere:
/opt/myapp/server
/srv/myapp/server
/usr/local/bin/myappExecStart= uses an absolute executable path, so there is no requirement for the binary to sit beside the .service file.
This distinction keeps service-manager configuration separate from application artifacts.
Vendor units belong under /usr
Package-managed software generally installs system units in the distribution’s system unit directory, commonly:
/usr/lib/systemd/systemSome systems historically expose /lib/systemd/system; on distributions with a merged /usr layout, /lib may be a symlink into /usr/lib.
An administrator should normally avoid editing a package-owned unit in place. A package upgrade can replace that file, and local modifications then become difficult to distinguish from vendor changes.
Suppose a package provides:
/usr/lib/systemd/system/example.serviceand the only required local change is the restart policy. A drop-in is more precise than copying and maintaining the entire vendor unit:
sudo systemctl edit example.serviceThe resulting local override is typically stored under:
/etc/systemd/system/example.service.d/override.confwith content such as:
[Service]
Restart=on-failure
RestartSec=3sThe vendor unit remains package-managed while the local policy stays under /etc.
/run/systemd/system is temporary
/run is runtime state. Unit files placed under:
/run/systemd/systemcan affect the current boot but are not intended to survive a reboot.
This is useful for generated or temporary configuration. It is a poor location for a manually maintained production service that must remain available after the machine restarts.
The precedence relationship also matters:
/etc/systemd/system
↓
/run/systemd/system
↓
/usr/local/lib/systemd/system
↓
/usr/lib/systemd/systemA persistent administrator definition under /etc can therefore override a same-named runtime or vendor definition lower in the load path.
A unit file can remain outside the normal directories
Sometimes a project keeps its unit file with the source tree:
/opt/myapp/deploy/myapp.serviceIt does not have to be copied manually into /etc/systemd/system. systemctl link can make an external unit available through the unit search path:
sudo systemctl link /opt/myapp/deploy/myapp.serviceThis creates a link in the unit configuration area pointing to the external file.
There is an operational consequence: the target path must remain available whenever systemd needs the unit. Moving or deleting the project directory breaks the link. For deployed services, installing a stable unit under /etc/systemd/system is often easier to reason about than linking to a mutable source checkout.
daemon-reload and service reload are different operations
After creating or manually changing a unit file, reload the systemd manager configuration:
sudo systemctl daemon-reloadThis makes systemd reload unit files and rebuild its dependency information.
It is different from:
sudo systemctl reload myapp.serviceThe latter asks the service itself to reload application-specific configuration, if the service supports that operation. It does not mean “reread this .service file.”
A typical sequence after installing a new custom unit is:
sudo systemctl daemon-reload
sudo systemctl enable myapp.service
sudo systemctl start myapp.serviceenable and start also describe different states. Starting activates the unit now. Enabling creates the links described by the unit’s [Install] section so it can be pulled in automatically by targets such as multi-user.target.
To perform both operations for a newly installed service:
sudo systemctl enable --now myapp.serviceEnabling a service does not move its unit file
A common misconception is that systemctl enable copies a service into a special startup directory. It normally creates symlinks according to the [Install] section.
For:
[Install]
WantedBy=multi-user.targetenabling the service commonly creates a relationship resembling:
/etc/systemd/system/multi-user.target.wants/myapp.service
-> /etc/systemd/system/myapp.serviceor a link to the unit’s actual installed location.
The .wants/ link expresses dependency wiring. The original unit remains where it was installed.
This is also why a service can be started while disabled:
sudo systemctl start myapp.serviceand enabled while not currently running:
sudo systemctl enable myapp.serviceRuntime activation and boot-time enablement are separate concepts.
Inspect the definition systemd actually loaded
When several directories, symlinks, or drop-ins are involved, inspect the effective unit instead of guessing.
systemctl cat myapp.serviceTo see the primary unit fragment path:
systemctl show myapp.service -p FragmentPathFor example:
FragmentPath=/etc/systemd/system/myapp.serviceLocal differences from vendor configuration can also be inspected with:
systemd-deltaThese commands are especially useful after package upgrades or when a machine has accumulated old overrides.
Location expresses ownership
The directory containing a unit file is part of system administration policy, not a requirement on where the application binary must run.
A useful ownership model is:
/usr/lib/systemd/system/
distribution or package-managed units
/usr/local/lib/systemd/system/
locally installed system units
/run/systemd/system/
runtime-only units
/etc/systemd/system/
persistent administrator configuration and overridesFor a custom application managed directly on a server, placing the unit under /etc/systemd/system makes its ownership explicit. For packaged software, keeping the vendor unit under /usr/lib and applying local changes through /etc preserves the boundary between package state and administrator policy.
That boundary is the main reason the systemd unit search path has multiple directories. The paths are not interchangeable storage locations; their ordering gives local configuration a controlled way to override lower-priority definitions without rewriting them.