What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
systemd is Linux’s system and service manager. Running as process ID 1, it initializes the machine, starts and supervises user-space services, and coordinates shutdown. It represents most managed objects as units; a unit file describes what that object is, how it is activated, and how it relates to other units.
Once you understand unit types, file precedence, dependencies, and the difference between enabling and starting, you can operate services safely without editing package-owned files or guessing why a change had no effect.
What systemd and a unit are
The systemd manager reads unit configuration, builds a transaction of jobs, activates units in the required order, and monitors them afterward. A unit can be a long-running process, a listening endpoint, a mount, a timer, or another kernel- or filesystem-related object. The filename suffix identifies the unit type.
| Suffix | Purpose | Typical use |
|---|---|---|
.service |
Controls a daemon or other process. | Web server, worker, database, or one-shot command. |
.socket |
Represents a listening socket and can trigger a service when traffic arrives. | Socket activation for a network or local IPC service. |
.target |
Groups units into a logical state. | Boot milestones or an administrative collection of services. |
.mount |
Describes a mounted filesystem. | A data volume mounted at a path. |
.swap |
Represents a swap device or file. | Activating swap during boot. |
.timer |
Schedules activation of another unit. | Periodic maintenance or delayed jobs. |
.path |
Watches filesystem paths and activates a unit when they change. | Processing a file placed in a spool directory. |
.slice |
Groups processes for resource control. | Applying CPU or memory policy to a class of services. |
.scope |
Tracks externally created processes. | Processes started by another manager or session. |
.device |
Represents a kernel device. | Making a device available as a dependency. |
.automount |
Represents an automount point. | Mounting a filesystem when its path is first accessed. |
Some units are generated dynamically by systemd or other generators instead of coming from a permanent file. Therefore, the absence of a static file does not prove that a unit cannot exist.
#1 Best Overall
Where unit files live and which copy wins
Systemd searches compiled-in unit directories. For normal system administration, the important precedence order is:
/etc/systemd/system— administrator configuration, highest precedence./run/systemd/system— runtime configuration, normally temporary.- Vendor directories such as
/usr/lib/systemd/system— files installed by the operating system or a package.
If the same unit name appears in more than one location, the higher-precedence copy is used. Package updates can replace vendor files, so editing a file below /usr/lib/systemd/system is fragile and may be undone without warning.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Use drop-ins for local changes
A drop-in is a small fragment stored in a name-specific directory such as /etc/systemd/system/example.service.d/. It is read in addition to the main unit file and lets you change only the settings you own. Multiple drop-ins are merged in lexicographic filename order, so a later filename can override an earlier one.
After creating or changing a drop-in, inspect the result with systemctl cat example.service. That command displays the main file and the drop-ins systemd considers, making it easier to verify that the intended setting is present.
Anatomy of a unit file
Unit files use INI-style sections. The directives accepted by each section depend on the unit type and the systemd release installed by your distribution.
| Section | Role | Common directives |
|---|---|---|
[Unit] |
Human-readable identity and relationships with other units. | Description=, After=, Before=, Wants=, Requires=. |
[Service] |
How a process is started, supervised, restarted, and run. | ExecStart=, Restart=, User=, EnvironmentFile=, plus the service’s Type=, timeout, and resource-control settings. |
[Install] |
Metadata used when a unit is enabled. | WantedBy= and Alias=. |
Description= supplies the label shown by status commands. ExecStart= identifies the command for a service, while User= can run it as a dedicated account instead of the default service context. EnvironmentFile= points to a file containing environment assignments. Restart= expresses the desired restart policy when the process exits. Exact behavior and available values vary by systemd version, so consult the manual installed on the server when using less common directives.
A minimal service example
[Unit]
Description=Example worker
After=network-online.target
[Service]
Type=simple
ExecStart=/opt/example/bin/worker
User=example
Restart=on-failure
[Install]
WantedBy=multi-user.targetThis file describes a process, asks systemd to order it after the named network target, runs it as user example, and records that enabling should attach it to multi-user.target. The example does not itself guarantee network connectivity; ordering and dependency relationships are separate concepts.
Dependencies and ordering are different
Requires= and Wants= describe a pull-in relationship. They tell systemd that another unit should be started as part of the transaction. Requires= is the stronger requirement; Wants= expresses a softer preference.
After= and Before= describe ordering only. They constrain which job is processed first but do not, by themselves, cause either unit to be started. Two units can have a requirement relationship and still start in parallel unless an ordering relationship is also declared.
Designing a correct relationship
- Add the smallest requirement that reflects reality. Unnecessary requirements make failures propagate farther than needed.
- Add an ordering directive when the consumer truly must wait for the provider.
- Use activation mechanisms that express the relationship naturally. A socket can activate a service when a client connects; a timer can activate a job at a scheduled time; a path, device, or bus can provide its own trigger.
- Do not use
After=as a substitute for a dependency. It changes sequence, not membership in the transaction.
When diagnosing a graph, systemctl list-dependencies example.service shows units pulled in by the transaction. Compare that graph with the actual requirement: a service that merely needs a network socket may not need to require an entire network target.
Enable, start, reload, restart, and mask
These commands change different aspects of a unit’s lifecycle. “Enabling and starting units is orthogonal,” as the systemctl manual puts it.
| Command | What it does | What it does not do |
|---|---|---|
systemctl enable NAME |
Creates the symlinks described by the unit’s [Install] section. |
It does not activate a currently stopped unit. |
systemctl start NAME |
Activates the unit now. | It does not arrange activation at the next boot. |
systemctl enable --now NAME |
Enables the unit and immediately starts it. | It does not replace a later restart after configuration changes. |
systemctl daemon-reload |
Makes the manager reread unit files and drop-ins. | It does not restart a running process. |
systemctl restart NAME |
Stops and starts the unit using its current configuration. | It does not create enablement links. |
systemctl mask NAME |
Links the unit name to /dev/null, blocking activation. |
It does not merely stop the process; unmasking is required before activation. |
A safe workflow for installing or changing a service
- Inspect the current definition. Run
systemctl status example.servicefor state and recent messages, thensystemctl cat example.serviceto see the main file and drop-ins. - Check available names and enablement. Use
systemctl list-unit-files 'example*'. This distinguishes an installed unit from one that is currently active. - Create an administrator-owned drop-in. Put local changes under
/etc/systemd/system/example.service.d/instead of modifying the vendor file. - Reload manager configuration. Run
systemctl daemon-reload. This step is required after editing a unit file; it does not itself restart the process. - Apply the change. Start, restart, or stop the service as appropriate. Use
systemctl enable --now example.servicewhen you need both boot-time enablement and immediate activation. - Verify the dependency graph and runtime properties. Run
systemctl list-dependencies example.serviceandsystemctl show example.serviceto inspect dependencies, exit status, user, environment, and resource-control properties. - Read the unit’s journal. Run
journalctl -u example.serviceand correlate timestamps with the status output.
Commands and the properties returned by systemctl show vary slightly between systemd releases and Linux distributions. Use the local manual pages for release-specific options.
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!
Overriding a vendor service without breaking updates
Start by identifying the packaged unit with systemctl cat. Decide whether the change is a single setting, an additional environment file, or a complete redesign. For a focused change, create a drop-in with a descriptive, ordered filename such as 10-environment.conf or 50-resources.conf. Keep each concern separate so a later administrator can remove or audit it easily.
Remember that directives are merged according to their semantics. A scalar setting normally replaces the previous value, while list-valued settings may accumulate. If a list must be replaced rather than extended, use the directive’s documented reset form for your systemd version before adding the new entries. Always inspect the merged result with systemctl cat, run systemctl daemon-reload, and then restart or start the unit.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When a package update changes the vendor file, your drop-in remains in /etc. Review it after major upgrades because a local assumption about command paths, users, or dependencies may no longer match the new package.
Templates, instances, and aliases
A template unit has an @ before its suffix, for example worker@.service. Starting worker@blue.service 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.
Instance-specific data can be supplied through an environment file, a distinct command argument, or another directive that references %i. Treat the instance value as input: use documented escaping rules and avoid constructing unsafe shell commands from it.
An Alias= entry in [Install] creates an alternate name when the unit is enabled. The alias does not create a second implementation; it is another name that points to the same unit.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteRank #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!
Diagnosing a failed service
The file was edited but nothing changed
Run systemctl daemon-reload first, then confirm the effective content with systemctl cat. If the process is already running, reload alone cannot change its command line; restart it when the service supports that operation.
The service exits immediately
Use systemctl status for the reported result and journalctl -u for the detailed error. Check the executable path in ExecStart=, the account from User=, environment supplied by EnvironmentFile=, and any required dependency. systemctl show exposes the manager’s recorded exit status and effective properties.
The service starts manually but not at boot
Manual activation proves only that start works now. Check systemctl list-unit-files to verify enablement and inspect the [Install] section’s WantedBy= or alias metadata. If the unit is intentionally blocked, systemctl mask may have linked its name to /dev/null; unmask it before enabling.
Repeated failures leave the unit blocked
After correcting the cause, use systemctl reset-failed example.service to clear the recorded failed state, then start the unit again. Review the journal before resetting so the evidence is not lost from your troubleshooting workflow.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choosing an activation and supervision design
| Design axis | Questions to answer |
|---|---|
| Activation model | Should the unit follow a boot target, wait for a socket connection, react to a path or device, run on a timer, or be started manually? |
| Dependency correctness | Which units must be pulled in, and which only need ordering? |
| Override safety | Can a drop-in express the change, or is a separately maintained unit justified? |
| Process supervision | What Type=, restart policy, timeout, user, and resource controls match the process? |
| Observability | Can an operator determine state, exit status, effective environment, dependencies, and journal history with standard commands? |
Prefer the simplest activation mechanism that matches the workload. A long-running daemon generally belongs in a service unit; a periodic task is clearer as a timer paired with a service; a demand-driven endpoint may be better represented by a socket. Keeping these roles distinct makes failures easier to isolate and avoids forcing every task into a boot-time process.
Quick Recap
Operational checklist
- Identify the unit type from its suffix before choosing directives.
- Check the effective file and drop-ins with
systemctl cat. - Keep administrator changes in
/etc/systemd/system, preferably in a drop-in directory. - Separate dependency pull-in (
Requires=orWants=) from ordering (After=orBefore=). - Remember that enablement affects future activation, while start affects the current transaction.
- Run
daemon-reloadafter file changes, then restart when a running process must consume them. - Use status, show, dependency, and journal commands together rather than relying on one output.
- Clear a resolved failed state with
reset-failedonly after recording the diagnostic evidence.
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.
