Systemd Cheatsheet - Systemd Service Management Command Reference
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.
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 nginxsystemctl stop nginxsystemctl restart nginxsystemctl reload nginxsystemctl enable nginxsystemctl disable nginxsystemctl enable --now nginxsystemctl mask nginxStatus 7
systemctl status nginxsystemctl is-enabled nginxsystemctl is-active nginxsystemctl is-failed nginxsystemctl list-units --type=servicesystemctl list-unit-files --type=servicesystemctl list-units --failedjournalctl 8
journalctl -u nginxjournalctl -u nginx -fjournalctl --since "10 min ago" -u nginxjournalctl --since today --until "1 hour ago"journalctl -p err -bjournalctl -u nginx -n 100 --no-pagerjournalctl --disk-usagejournalctl --vacuum-size=100MTargets & Runlevels 6
systemctl get-defaultsystemctl set-default multi-user.targetsystemctl set-default graphical.targetsystemctl isolate multi-user.targetsystemctl rescuesystemctl list-units --type=targetTimers 6
systemctl list-timerssystemctl list-timers --allsystemctl status <timer>systemctl start <timer> && systemctl enable <timer>systemctl cat <timer>journalctl -u <timer>Service Config & Resource Control 6
systemctl cat nginxsystemctl edit nginxsystemctl edit --full nginxsystemctl daemon-reloadsystemctl set-property nginx CPUQuota=50%systemctl set-property nginx MemoryMax=512MTroubleshooting & Analysis 6
systemctl --failedsystemctl reset-failed nginxsystemd-analyze timesystemd-analyze blamesystemd-analyze critical-chain nginxsystemctl daemon-reloadParameter matrix
| Parameter | Effect | Example |
|---|---|---|
enable --now | 设置开机自启并立即启动（一步完成两件事） | systemctl enable --now nginx |
reload vs restart | 平滑重载不断连接 / 重启进程会断连接 | systemctl reload nginx |
mask vs disable | 彻底禁用（无法被间接拉起）/ 仅取消自启 | systemctl mask nginx |
status | 查看状态、最近日志与 PID | systemctl status nginx |
is-active / is-enabled | 脚本友好：运行中 / 已自启的退出码 | systemctl is-active nginx |
--failed | 列出所有失败的服务 | systemctl --failed |
journalctl -u -f | 按单元过滤并实时跟踪 | journalctl -u nginx -f |
--since / --until | 按时间窗口过滤日志 | journalctl --since "10 min ago" -u nginx |
-p err -b | 本次开机以来的 error 及以上 | journalctl -p err -b |
--vacuum-size | 清理日志只保留指定大小 | journalctl --vacuum-size=100M |
list-timers | 查看定时任务，替代 crontab -l | systemctl list-timers |
daemon-reload | 改完单元文件后重新加载（必做） | systemctl daemon-reload |
set-property | 运行时限制 CPU 与内存 | systemctl set-property nginx MemoryMax=512M |
systemd-analyze blame | 按耗时排序列出各服务启动时间 | systemd-analyze blame |
Common pitfalls
Symptom改了单元文件，systemctl restart 后配置依然没生效。
Cause修改单元文件后 systemd 不会自动重新读取配置。
Fix执行 systemctl daemon-reload 再 restart；systemctl edit 生成的 override.conf 同理。
Symptom服务反复启动失败，status 显示 Restarting 循环。
CauseExecStart 路径不存在、权限不足或依赖服务未就绪，systemd 按 Restart 策略反复重试。
Fixjournalctl -u <服务> -n 100 --no-pager 看真实报错；用 systemctl cat 核对 ExecStart 路径。
Symptom服务已经 enable，但重启机器后没有自启。
Causeenable 只写了自启链接，而服务被 mask 过，mask 优先级高于 enable。
Fixsystemctl is-enabled <服务> 确认真实状态；如为 masked 先 systemctl unmask。
Symptomrestart 后客户端全部连接断开，业务出现瞬时错误。
Causerestart 会终止旧进程再启动，断开了所有已建立连接。
Fix支持 reload 的服务（nginx）改用 systemctl reload 做平滑重载，不断连接。
Symptom磁盘被 journal 日志占满。
Causejournal 默认轮转但上限可能很大，长期无人清理。
Fixjournalctl --disk-usage 查看占用，journalctl --vacuum-size=100M 清理；并可配置 SystemMaxUse。
Symptom启动变慢，journalctl 报启动超时。
Cause某个服务单元配置了过长的 TimeoutStartSec，依赖服务慢时会卡住整体启动。
Fixsystemd-analyze blame 找出耗时最长的单元，systemd-analyze critical-chain 看依赖链后针对性处理。
Symptom手动 stop 服务后，过一会又被其他服务拉起来了。
Cause该服务被另一个单元（如 target 或 Requires 依赖）作为依赖启动。
Fixsystemctl list-units --type=service 查反向依赖；确需彻底停用时用 systemctl mask。
Troubleshooting
1服务不工作时的标准四步
systemctl status nginx && journalctl -u nginx -n 100 --no-pagerstatus 看状态与最近日志，journalctl 拉完整历史；这两步能解决多数启动失败。
2确认配置是否真的被读取
systemctl cat nginx同时列出主单元文件与 override 片段，排查配置被覆盖时必看。
3改完单元文件让配置生效
systemctl daemon-reload && systemctl restart nginxdaemon-reload 漏掉是最常见的「改了没反应」原因。
4实时盯日志配合改配置
journalctl -u nginx -f另开终端改配置并 reload，错误是否消失一眼可见。
5脚本里判断服务状态
systemctl is-active nginx || systemctl restart nginxis-active 以退出码表达状态，适合写进健康检查脚本。
Command Examples
Status plus recent logs when a service will not start
systemctl status nginxstatus 把加载状态、运行状态、启动时间和主进程都打出来，是排查第一步。要跟实时日志就在同一命令加 -f 或改用 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 支持相对时间，"10 min ago" 比写绝对时间省事。加 --no-pager 防止输出进 less 而在脚本里卡住。
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 | headblame 按耗时排序列出各服务，critical-chain <unit> 则展开某个服务的依赖链。优化启动时间先看排在最前面的那几个。
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.
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