A systemd unit is a named object that systemd can start, stop, monitor, or otherwise manage on a Linux server. A unit file describes that object and its relationships to other units. Service files are only one kind: systemd also manages sockets, timers, mounts, devices, targets, slices, scopes, paths, swaps, and automount points.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To work safely, separate four tasks: defining a unit, establishing dependencies and ordering, enabling activation at boot, and starting or restarting the process now. Store administrator changes in /etc/systemd/system or a drop-in directory, run systemctl daemon-reload after editing, and use systemctl status plus journalctl -u to verify the result.
As an Amazon Associate I earn from qualifying purchases.
Free tools Windows power users keep installed
One-click scans. No signup required.
What systemd does and what a unit represents
systemd is the Linux system and service manager. When it runs as process ID 1, it initializes the machine and maintains userspace services. Its manager keeps a state model of resources and jobs rather than treating every startup script as an isolated command. Most objects in that model are represented by units, and most units are described by unit configuration files.
A unit has a name, a type, a state, and relationships with other units. The suffix in the filename identifies the type. Some units are generated dynamically by systemd or distribution tooling, so not every unit visible to the manager has a hand-written file in a persistent directory.
#1 Best Overall
Common unit types
| Suffix | What it represents |
|---|---|
.service |
A daemon or other supervised process. |
.socket |
A listening socket that can activate a service when traffic arrives. |
.target |
A grouping and synchronization point for other units. |
.mount |
A mounted filesystem. |
.swap |
A swap device or swap file managed by systemd. |
.timer |
A schedule that activates another unit. |
.path |
A filesystem-change trigger. |
.slice |
A hierarchy for grouping processes and applying resource controls. |
.scope |
Externally created processes tracked by systemd. |
.device |
A kernel device exposed through the device manager. |
.automount |
An automount point that mounts a filesystem when accessed. |
A service may therefore be activated directly, by a socket, on a timer, after a path change, when a device appears, or as part of a target. Choosing the activation unit is an architectural decision, not merely a syntax choice.
Where unit files live and which copy wins
systemd searches compiled-in unit paths, with administrator configuration taking precedence over runtime and vendor configuration. The usual precedence from highest to lowest is:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
/etc/systemd/systemfor persistent administrator configuration./run/systemd/systemfor runtime-created administrator or generator output.- Vendor directories such as
/usr/lib/systemd/system, normally populated by packages.
Distribution builds can include additional compiled-in paths, so inspect the local system when a package uses an unusual location. A file in a higher-precedence directory with the same unit name takes effect instead of the lower-precedence file. Replacing a vendor file in place is fragile because a package upgrade can overwrite it.
Drop-ins are the normal override mechanism
For a unit named example.service, create a directory such as /etc/systemd/system/example.service.d/ and put a small fragment there, for example 10-local.conf. The fragment adds settings or overrides compatible settings without copying the vendor unit. Drop-ins from the unit’s directories are merged in lexicographic filename order, so a later filename can override an earlier one when the directive’s semantics allow it.
Use systemctl cat example.service to display the effective main file together with its drop-ins. This is more reliable than opening only the vendor file because it shows the configuration systemd is actually assembling.
Anatomy of a unit file
Unit files use INI-like sections. The directives accepted in each section depend on the unit type and the systemd release, so consult the local manual when using a less common option.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall| Section | Purpose | Typical directives |
|---|---|---|
[Unit] |
Description and relationships with other units. | Description=, After=, Before=, Wants=, Requires= |
[Service] |
How a process is launched, supervised, stopped, and attributed. | ExecStart=, Restart=, User=, EnvironmentFile=, Type=, timeout and resource-control settings |
[Install] |
Metadata used when enabling the unit. | WantedBy=, RequiredBy=, Alias= |
A minimal illustrative service might look like this:
[Unit]
Description=Example worker
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=worker
EnvironmentFile=-/etc/example/worker.env
ExecStart=/usr/local/bin/worker-app
Restart=on-failure
[Install]
WantedBy=multi-user.targetThe example’s path, user, and environment file are placeholders for a real installation: verify that the executable and account exist before starting it. EnvironmentFile=-... uses a leading hyphen to make a missing optional file non-fatal; remove the hyphen when the file must exist.
Dependencies and ordering are different dimensions
Requires= and Wants= express a pull-in relationship. They tell systemd to start another unit when this unit is started. Requires= is stronger: failure or stopping of the required unit can affect the requiring unit. Wants= is a softer request; the wanted unit’s failure does not by itself make the requesting unit fail.
After= and Before= express ordering only. They constrain the sequence when both units are being activated, but they do not pull either unit into a transaction. Two units can have a requirement relationship and still start in parallel unless an ordering relationship is also declared. Conversely, two units can be ordered without one requiring the other.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Building a correct relationship
- Use the smallest requirement set that reflects what the process genuinely needs.
- Add an ordering directive when readiness or shutdown sequence matters.
- Do not use
After=as a substitute for starting a dependency; it does not activate anything. - Prefer native activation paths, such as a socket, bus name, timer, path, or device unit, when they make a direct dependency unnecessary.
- Inspect the resulting graph with
systemctl list-dependencies example.serviceinstead of assuming that a target name describes readiness.
For example, a web process that needs a local database may use Requires=database.service and After=database.service when the database must be running first. A process that merely benefits from an optional metrics collector may use Wants=metrics.service without making collector failure take down the main service.
Enable, start, reload, restart, and mask
These commands change different things. Enabling affects future activation; starting affects the current boot. The systemctl manual describes them as orthogonal operations.
Rank #3
- Linux Mint 22 on a Bootable 8 GB USB type C OTG phone compatible storage
- The preinstalled USB stick allows you to learn how to learn to use Linux, boot and load Linux without uninstalling your current OS
- Comes with an easy-to-follow install guide. 24/7 software support via email included.
- Comprehensive installation includes lifetime free updates and multi-language support, productivity suite, Web browser, instant messaging, image editing, multimedia, and email for your everyday needs
- Boot repair is a very useful tool! This USB drive will work on all modern-day computers, laptops or desktops, custom builds or manufacture built!
| Command | Effect |
|---|---|
systemctl enable NAME |
Creates the symlinks described by the unit’s [Install] metadata. It does not start the unit now. |
systemctl start NAME |
Requests activation immediately. |
systemctl enable --now NAME |
Enables the unit for its normal boot target and starts it immediately. |
systemctl restart NAME |
Stops and starts the unit now, subject to its type and stop/start behavior. |
systemctl daemon-reload |
Re-reads unit files and drop-ins. It does not restart a running process. |
systemctl mask NAME |
Links the unit name to /dev/null, preventing activation until it is unmasked. |
Use systemctl unmask NAME to remove a mask. Masking is stronger than disabling: a disabled unit can still be started manually or pulled in by another unit, while a masked unit cannot be activated under that name.
A safe edit-and-verify workflow
- Inspect the current state. Run
systemctl status example.service. Note whether it is active, failed, restarting, which command ran, and the latest log lines. - Inspect the assembled configuration. Run
systemctl cat example.service. Confirm the main file and every drop-in shown are the files you intended to use. - Check installation metadata and dependencies. Run
systemctl list-unit-files 'example*'andsystemctl list-dependencies example.service. The first shows known unit-file states; the second shows the activation tree. - Edit a local file or drop-in. Prefer
/etc/systemd/system/example.servicefor a fully administrator-owned unit, or/etc/systemd/system/example.service.d/20-local.conffor a vendor unit you are extending. - Validate the intended change. Check executable paths, account ownership, permissions, environment-file syntax, and referenced unit names before asking systemd to use the file.
- Reload manager configuration. Run
systemctl daemon-reload. This makes systemd reread files but leaves an already running process untouched. - Apply the process change. Run
systemctl restart example.servicefor a running service, orsystemctl start example.servicefor an inactive one. If it should also start at boot, usesystemctl enable --now example.servicewhen appropriate. - Read the result. Run
systemctl status example.serviceandjournalctl -u example.service. Confirm the active state, main PID, exit status, user, and recent messages. - Clear a stale failure counter when needed. After correcting the cause,
systemctl reset-failed example.serviceclears the failed state recorded for the unit; it does not fix the underlying configuration or start the service.
systemctl show example.service exposes individual manager properties, including exit status, selected user, environment-related settings, dependencies, and resource-control values. Property names and available fields vary slightly with the systemd release and distribution.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteTemplates, instances, and aliases
A template unit contains an @ before its suffix, such as [email protected]. Starting [email protected] selects that template and supplies blue as the instance string. In directives, %i expands to the unescaped instance identifier, allowing one definition to serve many similar workers.
[Service]
ExecStart=/usr/local/bin/worker --name %i
Restart=on-failureWith this template, systemctl start [email protected] passes blue to the command. Treat instance text as input: if it comes from an external naming system, verify the resulting path and arguments before enabling instances.
An Alias= entry in [Install] creates an alternate name when the unit is enabled. Aliases are useful for a stable operational name while the underlying unit name remains descriptive, but they do not create a second implementation or change the unit’s dependencies.
Overriding a vendor service without breaking upgrades
Use a drop-in for a targeted change
Create the name-specific directory under /etc/systemd/system, add a clearly numbered .conf file, run daemon-reload, and restart the unit. A drop-in is appropriate for changes such as a different User=, an environment file, a restart policy, or an additional relationship.
Recommended Free Tools
Rank #4
- Ubuntu Linux 22 on a Bootable 8 GB USB type C OTG phone compatible storage
- The preinstalled USB stick allows you to learn how to learn to use Linux, boot and load Linux without uninstalling your current OS
- Comes with an easy-to-follow install guide. 24/7 software support via email included.
- Comprehensive installation includes lifetime free updates and multi-language support, productivity suite, Web browser, instant messaging, image editing, multimedia, and email for your everyday needs
- Boot repair is a very useful tool! This USB drive will work on all modern-day computers, laptops or desktops, custom builds or manufacture built!
Know when a full replacement is justified
Copying a vendor file into /etc/systemd/system makes the administrator copy authoritative, but it also makes future vendor changes invisible until you compare and update the copy. Use a full replacement only when you intentionally own the complete definition. For a single directive, a drop-in is easier to audit and less likely to diverge after package updates.
Resetting list-valued directives
Some directives accept multiple values. A drop-in may need the directive’s documented reset form before adding a replacement list; otherwise the vendor entries can remain alongside yours. Check the unit-type manual for the exact reset syntax rather than assuming every directive merges the same way.
Diagnosing a failed or unexpectedly started service
Start with state and logs
systemctl status shows the active state, recent transition, main process, and a short journal excerpt. Follow it with journalctl -u example.service to see the unit’s complete journal records, including startup errors that scrolled out of the status view.
Check the effective command and identity
Common failures include a missing executable, an incorrect working directory, a service account without permission to read a file, or an environment variable that exists in an interactive shell but not in the manager’s environment. Use systemctl cat and systemctl show to verify ExecStart, User, environment settings, dependencies, and resource limits.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Interpret dependency and ordering symptoms
- If a dependency was never started, add an appropriate
Wants=orRequires=;After=alone cannot pull it in. - If both units start but the consumer races the provider, add an ordering relationship or use the provider’s socket or bus activation mechanism.
- If a unit is unexpectedly impossible to start, check whether it is masked and run
systemctl unmaskonly when that block is intentional no longer. - If a service repeatedly exits, inspect its exit status and journal before increasing restart limits; automatic retries can conceal a deterministic configuration error.
Remember the reload boundary
Editing a file without daemon-reload leaves the manager using its previously read configuration. Running daemon-reload without restarting leaves the old process running under the old settings. After both operations, verify the new main PID, command line, and environment where those properties matter.
How to evaluate a unit-file design
When choosing between designs, compare the operational dimensions that affect reliability and maintenance:
| Dimension | Questions to ask |
|---|---|
| Activation model | Should activation happen at a boot target, on socket traffic, on a timer, after a path change, when a device appears, or only manually? |
| Dependency correctness | Which relationships truly pull units in, and which merely order units that are already being activated? |
| Override safety | Can a drop-in express the change, avoiding a copy of a package-owned file? |
| Process supervision | Is Type= correct, is the restart policy deliberate, are timeouts suitable, and does the service run as the least-privileged practical user? |
| Resource control | Should the unit belong to a slice or have explicit CPU, memory, I/O, or task limits? |
| Observability | Can an operator identify the main process, exit status, dependencies, and relevant journal records from standard tools? |
A unit file is successful when its activation trigger, relationship graph, supervision policy, and diagnostic path all match the workload. Keeping those concerns explicit makes failures easier to isolate and upgrades less risky.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
