systemctl sends requests to a systemd manager. This lesson focuses on system service units. Confirm the exact unit name, manager scope, dependencies, and operational impact before changing state.
Init · Lesson 6
Systemd Goals
Learn how to inspect, override, validate, start, enable, and troubleshoot systemd service units.
Reading a Service Unit
A minimal illustrative unit can look like:
[Unit]
Description=Example worker
Wants=network-online.target
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]contains description and dependency relationships.[Service]defines process lifecycle and service-specific behavior.[Install]tells enablement commands which aliases or dependency links to create; it is not automatically an active runtime dependency.
ExecStart= is not passed through a shell by default. Shell pipelines, redirections, variables, and quoting do not behave like an interactive command line unless an explicit shell is intentionally invoked.
What is the primary purpose of [Install] directives such as WantedBy=?
Inspecting Effective Configuration
List loaded units with:
$ systemctl list-units --type=service
List installed unit files and enablement states with:
$ systemctl list-unit-files --type=service
These are different views: a unit file can be enabled but inactive, active but disabled, static, generated, transient, masked, or absent from one listing. Inspect merged vendor and drop-in content with:
$ systemctl cat UNIT.service
$ systemctl show UNIT.service
What does list-unit-files show that list-units does not primarily show?
Creating a Local Override
Use a drop-in rather than editing a packaged unit:
$ sudo systemctl edit UNIT.service
After saving, systemctl normally asks the manager to reload as part of this edit workflow on current implementations, but when files are changed by another method, run:
$ sudo systemctl daemon-reload
daemon-reload rereads unit definitions and rebuilds dependencies. It does not reload application configuration or restart running services. Validate unit syntax and dependencies with systemd-analyze verify where appropriate, then review the effective merged unit.
What does systemctl daemon-reload do?
Runtime Service State
After validating service configuration and preserving recovery access:
$ sudo systemctl start peanut.service
$ sudo systemctl stop peanut.service
$ sudo systemctl restart peanut.service
$ sudo systemctl reload peanut.service
reload succeeds only when the unit defines or supports a reload action. restart interrupts the process and can fail to restore service. For remote access, networking, storage, or authentication, keep a separate console path and verify configuration before acting.
Check state and logs with:
$ systemctl status peanut.service
$ systemctl is-active peanut.service
$ journalctl -u peanut.service -b
“Active” is manager state, not proof that every application endpoint is healthy.
Which command starts peanut.service now without changing future enablement by itself?
Enablement, Disablement, and Masking
Manage future dependency links with:
$ sudo systemctl enable peanut.service
$ sudo systemctl disable peanut.service
Enable does not start the unit unless --now is added. Disable does not stop a running unit unless --now is added. A static unit can lack install metadata and still be activated as another unit's dependency.
Masking links the unit to /dev/null and blocks ordinary activation, including dependency activation, until unmasked. It is stronger than disable and can break dependents; inspect reverse dependencies before using it.
What happens to an already running service after systemctl disable UNIT without --now?
Verify the Service Outcome
After a change, verify process state, recent logs, listening endpoints, dependent units, application health, and behavior across a controlled reboot if boot enablement changed. Use systemctl is-failed, systemctl list-dependencies, and application-native checks as appropriate.
Lesson complete
You finished Systemd Goals
You can now manage a systemd service without confusing configuration, runtime, and enablement.
Read
[Unit],[Service], and[Install]by their distinct roles.Compare loaded unit state with installed unit-file state.
Use drop-ins and reload the manager after external file changes.
Start, stop, reload, or restart only after impact review.
Treat enable, disable, and mask as separate persistence controls.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account