The essentials

Quick reference

One focused task per row. Jump to the related section for complete, working examples.

UseSyntaxExamples
List loaded servicessystemctl list-units --type=serviceView examples
List installed unit filessystemctl list-unit-files --type=serviceView examples
Inspect service statussystemctl status nginx.serviceView examples
Test active statesystemctl is-active --quiet nginx.serviceView examples
Read unit propertiessystemctl show nginx.service \ --property=ActiveState,SubState,MainPIDView examples
Show unit sourcesystemctl cat nginx.serviceView examples
Show dependenciessystemctl list-dependencies nginx.serviceView examples
Start a servicesudo systemctl start nginx.serviceView examples
Stop a servicesudo systemctl stop nginx.serviceView examples
Restart a servicesudo systemctl restart nginx.serviceView examples
Reload service configurationsudo systemctl reload nginx.serviceView examples
Enable and startsudo systemctl enable --now nginx.serviceView examples
Disable and stopsudo systemctl disable --now nginx.serviceView examples
Reload unit definitionssudo systemctl daemon-reloadView examples
Create a drop-in overridesudo systemctl edit nginx.serviceView examples
Read one unit's journaljournalctl --unit=nginx.service --no-pagerView examples
Limit to current bootjournalctl --boot=0View examples
Read previous bootjournalctl --boot=-1View examples
Filter by timejournalctl --since='1 hour ago' --until=nowView examples
Filter error prioritiesjournalctl --priority=err --boot=0View examples
Follow a unit livejournalctl --follow --unit=nginx.serviceView examples
Emit JSON recordsjournalctl --unit=nginx.service --output=json --lines=20View examples
Read kernel messagesjournalctl --dmesg --boot=0View examples

Diagnose before changing service state: inspect the unit definition, active state, dependencies, and recent journal together. Use exact unit names, distinguish starting now from enabling at boot, and treat reload, restart, daemon-reload, and reboot as different operations.

Step by step

Detailed examples

01

Distinguish loaded units from installed unit files

list-units describes units currently loaded into the manager and defaults to active, pending, or failed units unless --all is added. list-unit-files reports installed definitions and enablement states such as enabled, disabled, static, masked, or generated. A static unit can still start through dependencies even though it cannot be enabled directly.

Inventory services from both views
systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service | head
Output
# The first view is runtime state; the second is installed enablement state.
Back to quick reference ↑
02

Correlate state, definition, and dependencies

status is a human-oriented snapshot with recent journal lines. is-active is better for scripts because its exit status communicates state, while show exposes stable property names. cat reveals the fragment and drop-ins the manager loaded; list-dependencies helps explain activation relationships but does not by itself show every ordering edge.

Read one unit without changing it
systemctl status nginx.service --no-pager
systemctl show nginx.service --property=LoadState,ActiveState,SubState,MainPID,ExecMainStatus
systemctl cat nginx.service
systemctl list-dependencies nginx.service
Output
# Unit-specific state and paths vary by system.
Back to quick reference ↑
03

Choose start, stop, restart, or reload precisely

start and stop change current runtime state only. restart performs stop and start and may interrupt requests; reload asks the service to reread its own configuration only when the unit supports that action. Check configuration with the service's native validation command, review impact, then inspect status and logs after an authorized change.

Validate, reload, and verify an nginx service
sudo nginx -t
sudo systemctl reload nginx.service
systemctl status nginx.service --no-pager
journalctl --unit=nginx.service --since='5 minutes ago' --no-pager
Output
# Proceed with reload only after validation succeeds.
Back to quick reference ↑
04

Separate boot enablement from runtime state

enable creates the relationships described by a unit's [Install] section but does not start it unless --now is present. disable removes those links but does not stop a running unit unless --now is present. Masking is stronger and blocks activation through dependencies as well as manual starts; use it only when that policy is intended.

Inspect before changing enablement
systemctl is-enabled nginx.service
sudo systemctl enable --now nginx.service
systemctl is-enabled nginx.service
systemctl is-active nginx.service
Output
# Expected final states are enabled and active when the operation succeeds.
Back to quick reference ↑
05

Use drop-ins and reload manager configuration

systemctl edit creates an override under /etc rather than modifying a package-owned unit. After unit files change, daemon-reload makes the manager reread definitions; it does not restart affected services or reload their application configuration. Review the merged definition with systemctl cat and explicitly restart only when required.

Review an override workflow
sudo systemctl edit nginx.service
sudo systemctl daemon-reload
systemctl cat nginx.service
systemctl show nginx.service --property=FragmentPath,DropInPaths
# Restart separately only if the reviewed change requires it.
Output
# The editor and resulting paths depend on the system configuration.
Back to quick reference ↑
06

Narrow journal queries at the source

journalctl reads only records the current user is permitted to access. Combine --unit, --boot, --since, --until, and --priority so filtering occurs inside the journal reader rather than after a huge unbounded query. Boot history depends on retained journals, and a single priority includes that level and all more severe levels.

Recent service errors from this boot
journalctl --unit=nginx.service \
  --boot=0 \
  --since='1 hour ago' \
  --priority=err \
  --no-pager
Output
# Zero or more matching journal records are printed.
Compare current and previous boots
journalctl --list-boots
journalctl --boot=0 --lines=20 --no-pager
journalctl --boot=-1 --lines=20 --no-pager
Output
# Previous-boot output requires persistent or otherwise retained journal data.
Back to quick reference ↑
07

Follow live records or preserve structured fields

--follow waits for appended entries and is interactive until interrupted. JSON output preserves journal fields for tools, while the default short format is easier for people. Kernel messages are selected with --dmesg or -k. Logs can contain credentials, request data, internal addresses, and personal information, so redact before sharing.

Structured recent records
journalctl --unit=nginx.service --lines=20 --output=json --no-pager
journalctl --dmesg --boot=0 --priority=warning --no-pager
Output
# JSON mode emits one structured journal entry per line.
Follow one service until interrupted
journalctl --follow --unit=nginx.service
Output
# Press Ctrl+C to stop following new records.
Back to quick reference ↑

Keep exploring

More Linux cheat sheets

Sources and further reading

References

Authoritative documentation used to verify and expand this cheat sheet.

  1. systemd projectsystemctl — Control the systemd system and service managerfreedesktop.org
  2. systemd projectjournalctl — Print log entries from the systemd journalfreedesktop.org
  3. systemd projectsystemd.unit — Unit configurationfreedesktop.org
  4. systemd projectsystemd.service — Service unit configurationfreedesktop.org

Help us improve

Found a typo or missing example?

Tell us what would make this cheat sheet clearer, more complete, or more useful.

Share feedback