Systemd Goals

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.

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.

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

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.

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.

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.

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.

Summary

You can now manage a systemd service without confusing configuration, runtime, and enablement.

1. Read [Unit], [Service], and [Install] by their distinct roles.
2. Compare loaded unit state with installed unit-file state.
3. Use drop-ins and reload the manager after external file changes.
4. Start, stop, reload, or restart only after impact review.
5. Treat enable, disable, and mask as separate persistence controls.