LaoHandDeveloper Cheatsheet

Systemd Cheatsheet - systemctl, journalctl & Units

systemd deserves a pass on its own because on modern Linux distributions it unifies four things that people still split across three parallel toolchains: service management, log querying, scheduling and resource limits. Filtering journalctl by unit, by time window and by priority is far more precise than grepping files in /var/log, especially when a service dies immediately after start - combining --since with -p err narrows the output to this boot's errors. This sheet covers service control, status inspection, journal troubleshooting, targets and runlevels, timers, unit configuration and resource control, and failure analysis. Which group to open depends on the symptom: start and stop for the first, "where do the logs live" for the third, "how do I cap CPU and memory" for the sixth. The timer group is the replacement for crontab, and it wins on execution logs, dependency ordering and inspectable failures.

SysOps·47 commands·Last updated 2026-07-21
systemdsystemctljournalctlServices

Typical Use Case

For operators and back-end engineers managing long-running services on a Linux server. systemd replaces SysVinit scripts by unifying service state, boot enablement, logs, scheduled tasks and resource limits under one set of commands and one configuration model. Its real value is a fixed troubleshooting path: status for state, journalctl for logs, cat for configuration, daemon-reload to pick up changes. This sheet covers those four steps plus timers and resource limits, which together resolve almost every configuration problem.

Service Management 8

systemctl start nginx
Start the service into the running state; does not add it to boot-enable, so it goes away on reboot
systemctl stop nginx
Stop the running service, running its ExecStop before exit; does not touch whether it is enabled at boot
systemctl restart nginx
Stop then start again; drops active connections, so prefer reload when the process holds persistent sessions
systemctl reload nginx
Gracefully reload config without dropping connections; not all services support reload
systemctl enable nginx
Enable the service to start at boot; add --now to also start it immediately
systemctl disable nginx
Disable the service from starting at boot
systemctl enable --now nginx
Enable at boot and start immediately
systemctl mask nginx
Fully disable a service so it cannot be started manually or pulled in by other units

Status 7

systemctl status nginx
Show service state and recent logs (most common)
systemctl is-enabled nginx
Show whether the service is enabled at boot
systemctl is-active nginx
Show whether the service is currently running
systemctl is-failed nginx
Check whether the service is in a failed state
systemctl list-units --type=service
List all loaded service units
systemctl list-unit-files --type=service
List all installed service files and their boot-enable state
systemctl list-units --failed
List failed services to troubleshoot startup errors

journalctl 8

journalctl -u nginx
Show logs for the specified service
journalctl -u nginx -f
Follow the service's logs in real time
journalctl --since "10 min ago" -u nginx
Show logs from the last 10 minutes
journalctl --since today --until "1 hour ago"
Filter logs by a time range
journalctl -p err -b
Show logs at error level and above since boot
journalctl -u nginx -n 100 --no-pager
Show the last 100 log lines without paging
journalctl --disk-usage
Show how much disk space journal logs use
journalctl --vacuum-size=100M
Vacuum logs, keeping only the most recent 100 MB

Targets & Runlevels 6

systemctl get-default
Show the default boot target (equivalent to the runlevel)
systemctl set-default multi-user.target
Set the default to multi-user (command-line) mode
systemctl set-default graphical.target
Set the default to graphical desktop mode
systemctl isolate multi-user.target
Switch to multi-user mode immediately (equivalent to init 3)
systemctl rescue
Enter rescue mode (requires root; stops non-essential services)
systemctl list-units --type=target
List all currently active targets

Timers 6

systemctl list-timers
List all scheduled timers (replaces crontab -l)
systemctl list-timers --all
List all timers, including inactive ones
systemctl status <timer>
Show a timer's state and next execution time
systemctl start <timer> && systemctl enable <timer>
Enable a timer and start it at boot
systemctl cat <timer>
Show the timer unit file contents
journalctl -u <timer>
Show logs of the service triggered by the timer

Service Config & Resource Control 6

systemctl cat nginx
Show the service's unit file contents
systemctl edit nginx
Edit a service override config, stored in override.conf
systemctl edit --full nginx
Edit the full unit file (not as an override)
systemctl daemon-reload
Reload systemd configuration after editing unit files
systemctl set-property nginx CPUQuota=50%
Limit the service to at most 50% CPU
systemctl set-property nginx MemoryMax=512M
Cap the service's memory at 512 MB

Troubleshooting & Analysis 6

systemctl --failed
Quickly show all failed services
systemctl reset-failed nginx
Clear the failed state of a service
systemd-analyze time
Show total boot time
systemd-analyze blame
List each service's startup time, sorted by duration
systemd-analyze critical-chain nginx
Show the startup dependency chain for a service
systemctl daemon-reload
Required after editing unit files, otherwise config won't take effect

Parameter matrix

ParameterEffectExample
enable --nowEnable at boot and start immediately (two things in one step)systemctl enable --now nginx
reload vs restartGraceful reload without dropping connections / restarting the process drops themsystemctl reload nginx
mask vs disableFully disable (cannot be started indirectly) / merely cancel autostartsystemctl mask nginx
statusView status, recent logs, and PIDsystemctl status nginx
is-active / is-enabledScript-friendly exit codes: running / enabledsystemctl is-active nginx
--failedList all failed servicessystemctl --failed
journalctl -u -fFilter by unit and follow in real timejournalctl -u nginx -f
--since / --untilFilter logs by a time windowjournalctl --since "10 min ago" -u nginx
-p err -bErrors and above since this bootjournalctl -p err -b
--vacuum-sizeClean logs, keeping only the given sizejournalctl --vacuum-size=100M
list-timersList timers, replacing crontab -lsystemctl list-timers
daemon-reloadReload after editing a unit file (mandatory)systemctl daemon-reload
set-propertyLimit CPU and memory at runtimesystemctl set-property nginx MemoryMax=512M
systemd-analyze blameList each service startup time sorted by durationsystemd-analyze blame

Common pitfalls

SymptomAfter editing the unit file, the config still does not take effect after systemctl restart.

Causesystemd does not automatically reload configuration after a unit file is modified.

FixRun systemctl daemon-reload then restart; the same applies to override.conf created by systemctl edit.

SymptomThe service repeatedly fails to start, and status shows a Restarting loop.

CauseThe ExecStart path does not exist, permissions are insufficient, or a dependency is not ready; systemd retries per the Restart policy.

FixCheck the real error with journalctl -u <service> -n 100 --no-pager; verify the ExecStart path with systemctl cat.

SymptomThe service is already enabled, yet it does not start after a machine reboot.

Causeenable only writes the autostart link, but the service was masked, and mask takes precedence over enable.

FixConfirm the real state with systemctl is-enabled <service>; if it is masked, run systemctl unmask first.

SymptomAfter a restart all client connections drop and the service shows a momentary error.

Causerestart kills the old process before starting a new one, dropping all established connections.

FixFor services that support reload (nginx), use systemctl reload for a graceful reload without dropping connections.

SymptomThe disk is filled up by journal logs.

Causejournal rotates by default but the cap can be large, and it is left uncleaned for a long time.

FixCheck usage with journalctl --disk-usage and clean with journalctl --vacuum-size=100M; you can also configure SystemMaxUse.

SymptomStartup got slow and journalctl reports a startup timeout.

CauseSome service unit has an overly long TimeoutStartSec, stalling overall startup when a dependency is slow.

FixFind the slowest units with systemd-analyze blame, inspect the dependency chain with systemd-analyze critical-chain, then address it specifically.

SymptomAfter manually stopping the service, it gets pulled back up by another service a while later.

CauseThe service is started as a dependency by another unit (such as a target or a Requires dependency).

FixCheck reverse dependencies with systemctl list-units --type=service; when you truly want it disabled, use systemctl mask.

Troubleshooting

  1. 1The standard four steps when a service is not working

    systemctl status nginx && journalctl -u nginx -n 100 --no-pager

    status shows the state and recent logs, journalctl pulls the full history; these two steps resolve most startup failures.

  2. 2Confirm whether the config is actually being read

    systemctl cat nginx

    Lists both the main unit file and override fragments, essential when troubleshooting overridden config.

  3. 3Make the config take effect after editing the unit file

    systemctl daemon-reload && systemctl restart nginx

    Forgetting daemon-reload is the most common cause of "edited but nothing happened."

  4. 4Watch the log in real time while tweaking the config

    journalctl -u nginx -f

    Open another terminal, edit the config and reload; whether the error disappears is immediately visible.

  5. 5Check service state in a script

    systemctl is-active nginx || systemctl restart nginx

    is-active expresses state via exit code, ideal for health-check scripts.

Command Examples

Status plus recent logs when a service will not start

systemctl status nginx

status prints the load state, run state, startup time, and main process, the first step in troubleshooting. To follow real-time logs, add -f to the same command or switch to journalctl -u nginx -f.

Output

● nginx.service - A high performance web server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
   Active: active (running) since Mon 2026-09-29 10:12:03 CST; 2 days ago
  Process: 1420 ExecStart=/usr/sbin/nginx /etc/nginx/nginx.conf

Errors from the last 10 minutes only

journalctl -p err --since "10 min ago" -u nginx --no-pager

--since accepts relative times; "10 min ago" saves effort versus an absolute time. Add --no-pager to keep output from going into less and hanging in a script.

Output

Sep 30 14:02:11 host nginx[1420]: [error] 1420#1420: *3 open() "/usr/share/nginx/html/x" failed (2: No such file or directory)
Sep 30 14:02:11 host nginx[1420]: [error] 1420#1420: *3 connect() failed (111: Connection refused)

Find out why a service starts slowly

systemd-analyze blame | head

blame sorts services by duration; critical-chain <unit> expands a dependency chain. When optimizing startup time, look at the top few first.

Output

  1.204s NetworkManager-wait-online.service
  842ms docker.service
  231ms nginx.service
  118ms systemd-logind.service

Common Pitfalls

  • Editing a unit file without systemctl daemon-reload leaves systemd using the in-memory version, so nothing changes.
  • restart drops connections; prefer reload for a smooth switch, though not every service implements it.
  • enable only configures boot-time start and start only affects the current session; use enable --now for both.
  • systemctl edit writes an override.conf on top of the original — roll back by deleting that override.
  • Non-critical services are stopped in rescue or isolate targets; confirm which target you are in before running this on production.

Tips

  • reload gracefully reloads config without dropping connections, while restart recreates the process. Not all services support reload — nginx does.
  • journal logs rotate by default; if --disk-usage is too large, clean up with journalctl --vacuum-size=100M.
  • Timers are more controllable than crontab: you can see execution logs in journalctl and they support dependency relationships.
  • You must run systemctl daemon-reload after editing a unit file, otherwise systemd won't read the new config.
  • systemctl edit creates an override.conf snippet that doesn't modify the original unit file — safer.
  • mask is more thorough than disable: a masked service cannot be started manually or indirectly. Mask it before uninstalling a service.

FAQ

What is the difference between systemctl start and enable?

start only launches the service in the current session and it will not come back after a reboot; enable configures it to start at boot but does not start it now. They are independent, which is why systemctl enable --now nginx is the idiom for both. To check state, use systemctl is-enabled nginx and systemctl is-active nginx.

When can I not swap restart for reload?

reload applies new configuration without dropping existing connections and suits services like Nginx that support hot reloading; restart interrupts connections and starts over. Use restart only when the unit does not implement reload, or the change touches something that cannot be hot-swapped such as a listening port. Also note a syntax error will simply prevent the service from starting on restart — for Nginx, validate with nginx -t first.

Where do I look when a service will not start?

systemctl status nginx prints the state plus the last few log lines and is the one you will use most; journalctl -u nginx gives the full history and -f follows it live. Bound the window with journalctl --since "10 min ago" -u nginx, or restrict to error level and up with journalctl -p err -b. For a service that keeps restarting, systemctl show nginx explains why it exited.

Why does my systemd unit file change have no effect?

You must run systemctl daemon-reload so systemd re-reads configuration, then restart the service. Editing the file alone leaves systemd using the in-memory version. Prefer systemctl edit nginx for changes — it writes an override.conf instead of touching the original, so rolling back just means deleting that override.

How do I replace crontab with systemd timers?

Use a systemd timer — better suited when you need precise control, want the task to depend on service state, or want logs. systemctl list-timers shows every timer and its next run; after writing a matching .service and .timer pair, enable it with systemctl enable --now <timer>. Output goes to journalctl -u <service>, which is far easier to debug than cron mail.

Related Cheatsheets

6 related cheatsheets

Linux Troubleshooting Cheatsheet - System Fault Diagnosis Command ReferenceA one-stop Linux troubleshooting reference organized by process/load, port/network, disk/memory, and logs/services, helping you quickly spot performance bottlenecks, connection anomalies, and resource hogs during live incidents.Vim Cheatsheet - Modes, Editing & Search CommandsVim commands: motion, edit, search & replace, visual mode, save/exit, plus batch replace and sudo saves on servers.Cron Cheatsheet - Expressions & Task SchedulingCron schedules in five fields: use */5 for every five minutes, @daily for midnight runs, and crontab -e to edit while MAILTO routes task output.CI/CD Commands Cheatsheet - CI/CD Pipeline Debugging ReferenceA debugging reference for GitHub Actions, GitLab CI, and Jenkins pipelines, covering job reruns and log extraction, runner online status, cache and disk usage, and local reproduction with act or gitlab-runner exec.MQ Commands Cheatsheet - Kafka & RabbitMQMQ ops for Kafka and RabbitMQ: check lag with kafka-consumer-groups, list_queues backlog, spot leaks with ss, and run perf tests.tmux Cheatsheet - Terminal Multiplexer Command ReferenceFor anyone doing long-lived remote work over SSH, tmux keeps sessions, windows, and panes alive across disconnects — closing a window does not kill the work. This table groups create/delete/switch flows for sessions, windows and panes, copy-mode keystrokes, and common .tmux.conf settings.

Official References

Each command links to its official documentation below, so you can verify the latest usage and read deeper.

Maintained by LaoHand

Publicly updated on Jul 21, 2026, continuously proofread against official docs.

Contact Us

Wrong command or description? Send us corrections, business inquiries or product feedback by email.

Contact Us