Systemd 命令速查表 - Systemd 服务管理常用命令大全
systemd 值得专门过一遍的理由是：Linux 发行版里服务管理、日志查询、定时任务和资源限制这四件事被它统一到了一个模型下，而很多人至今在用 service、nohup 重定向和 crontab 三套并行方案。用 journalctl 按单元、按时间窗、按优先级过滤，比去 /var/log 里翻文件再 grep 精确得多，尤其是排查"服务启动后立刻挂掉"这类问题时，能把 --since 和 -p err 组合起来只看本次开机的错误。这张表覆盖服务管理、状态查看、日志排查、目标与运行级、timer 定时任务、服务配置与资源控制、故障排查与分析。判断该翻哪一组：启停用第一组，"日志去哪找"用第三组，"怎么限 CPU 内存"用第六组，timer 那组是 crontab 的替代方案，比 crontab 强在有执行日志、有依赖关系、有失败可查。
典型使用场景
面向管理 Linux 服务器上常驻服务的运维与后端工程师。systemd 替代了 SysVinit 的服务脚本，把「服务状态」「开机自启」「日志」「定时任务」「资源限制」统一到同一套命令与同一份配置语义里，真正的价值在于排障路径固定：status 看状态、journalctl 看日志、cat 看配置、daemon-reload 让配置生效。本表覆盖这四步以及 timer 与资源限制，配置类问题基本都能用这套流程定位。
服务管理 8
systemctl start nginxsystemctl stop nginxsystemctl restart nginxsystemctl reload nginxsystemctl enable nginxsystemctl disable nginxsystemctl enable --now nginxsystemctl mask nginx状态查看 7
systemctl status nginxsystemctl is-enabled nginxsystemctl is-active nginxsystemctl is-failed nginxsystemctl list-units --type=servicesystemctl list-unit-files --type=servicesystemctl list-units --failed日志排查（journalctl） 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=100M目标与运行级 6
systemctl get-defaultsystemctl set-default multi-user.targetsystemctl set-default graphical.targetsystemctl isolate multi-user.targetsystemctl rescuesystemctl list-units --type=targettimer 定时任务 6
systemctl list-timerssystemctl list-timers --allsystemctl status <timer>systemctl start <timer> && systemctl enable <timer>systemctl cat <timer>journalctl -u <timer>服务配置与资源控制 6
systemctl cat nginxsystemctl edit nginxsystemctl edit --full nginxsystemctl daemon-reloadsystemctl set-property nginx CPUQuota=50%systemctl set-property nginx MemoryMax=512M故障排查与分析 6
systemctl --failedsystemctl reset-failed nginxsystemd-analyze timesystemd-analyze blamesystemd-analyze critical-chain nginxsystemctl daemon-reload参数矩阵
| 参数 | 作用 | 示例 |
|---|---|---|
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 |
易错点与避坑指南
现象改了单元文件，systemctl restart 后配置依然没生效。
原因修改单元文件后 systemd 不会自动重新读取配置。
处置执行 systemctl daemon-reload 再 restart；systemctl edit 生成的 override.conf 同理。
现象服务反复启动失败，status 显示 Restarting 循环。
原因ExecStart 路径不存在、权限不足或依赖服务未就绪，systemd 按 Restart 策略反复重试。
处置journalctl -u <服务> -n 100 --no-pager 看真实报错；用 systemctl cat 核对 ExecStart 路径。
现象服务已经 enable，但重启机器后没有自启。
原因enable 只写了自启链接，而服务被 mask 过，mask 优先级高于 enable。
处置systemctl is-enabled <服务> 确认真实状态；如为 masked 先 systemctl unmask。
现象restart 后客户端全部连接断开，业务出现瞬时错误。
原因restart 会终止旧进程再启动，断开了所有已建立连接。
处置支持 reload 的服务（nginx）改用 systemctl reload 做平滑重载，不断连接。
现象磁盘被 journal 日志占满。
原因journal 默认轮转但上限可能很大，长期无人清理。
处置journalctl --disk-usage 查看占用，journalctl --vacuum-size=100M 清理；并可配置 SystemMaxUse。
现象启动变慢，journalctl 报启动超时。
原因某个服务单元配置了过长的 TimeoutStartSec，依赖服务慢时会卡住整体启动。
处置systemd-analyze blame 找出耗时最长的单元，systemd-analyze critical-chain 看依赖链后针对性处理。
现象手动 stop 服务后，过一会又被其他服务拉起来了。
原因该服务被另一个单元（如 target 或 Requires 依赖）作为依赖启动。
处置systemctl list-units --type=service 查反向依赖；确需彻底停用时用 systemctl mask。
排障路径
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 以退出码表达状态，适合写进健康检查脚本。
命令示例
服务起不来时一次看全状态与最近日志
systemctl status nginxstatus 把加载状态、运行状态、启动时间和主进程都打出来，是排查第一步。要跟实时日志就在同一命令加 -f 或改用 journalctl -u nginx -f。
输出
● 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
只看最近 10 分钟的错误日志
journalctl -p err --since "10 min ago" -u nginx --no-pager--since 支持相对时间，"10 min ago" 比写绝对时间省事。加 --no-pager 防止输出进 less 而在脚本里卡住。
输出
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)
查服务为何启动慢
systemd-analyze blame | headblame 按耗时排序列出各服务，critical-chain <unit> 则展开某个服务的依赖链。优化启动时间先看排在最前面的那几个。
输出
1.204s NetworkManager-wait-online.service 842ms docker.service 231ms nginx.service 118ms systemd-logind.service
常见坑与注意事项
- 改了单元文件不执行 systemctl daemon-reload，systemd 用的仍是内存里的旧配置，改动不会生效。
- restart 会中断连接，需要平滑切换时用 reload；但并非所有服务都实现了 reload。
- enable 只设开机自启不立即启动，start 只本次启动不自启，要两者兼得用 enable --now。
- systemctl edit 修改会写入 override.conf 覆盖原文件，回滚需删掉该 override。
- 在 rescue 或 isolate 目标下非关键服务会被停止，生产环境执行前确认当前处于哪个 target。
提示
- reload 是平滑重载配置不会断连接，restart 会重启进程；不是所有服务都支持 reload，nginx 支持。
- journalctl 日志默认会轮转，--disk-usage 太大时用 journalctl --vacuum-size=100M 清理。
- timer 比 crontab 更可控，能在 journalctl 里看执行日志，且支持依赖关系。
- 修改单元文件后必须执行 systemctl daemon-reload，否则 systemd 不会读取新配置。
- systemctl edit 创建的是 override.conf 覆盖片段，不会修改原始单元文件，更安全。
- mask 比 disable 更彻底，被 mask 的服务无法被手动或间接启动，卸载服务前可先 mask。
- `systemd-analyze blame` 排出开机各服务耗时，找卡住启动的那个比逐个 status 快。
- `systemctl set-property` 设的 CPUQuota/MemoryMax 重启后失效，要持久化须写进 unit 的 [Service] 段。
- `is-enabled` / `is-active` / `is-failed` 三个非交互查询适合写进健康检查脚本。
常见问题
systemctl start 和 enable 有什么区别？
start 只在当前会话里启动服务，重启机器后不会自动拉起；enable 是设置开机自启，但不会立刻启动。两者独立，systemctl enable --now nginx 才是「既设自启又立刻启动」的组合写法。排查时可以用 systemctl is-enabled nginx 和 systemctl is-active nginx 分别确认这两个状态。
restart 和 reload 什么时候不能互换？
reload 是平滑重载配置，不断开现有连接，适合 Nginx 这类支持热加载的服务；restart 会中断连接重来。只有当服务不实现 reload、或者配置改动涉及监听端口等无法热更新的部分时才必须 restart。另外 restart 前的修改若是语法错误，会直接导致服务起不来，Nginx 建议先 nginx -t 验证。
服务起不来时该从哪里看日志？
systemctl status nginx 会同时打印服务状态和最近几行日志，最常用；要看完整历史用 journalctl -u nginx，加 -f 可以实时跟踪。限定时间范围用 journalctl --since "10 min ago" -u nginx，只看 error 及以上级别用 journalctl -p err -b。频繁重启的服务还要看 systemctl show nginx 看它具体为何退出。
改了 systemd 单元文件后为什么没生效？
必须执行 systemctl daemon-reload 让 systemd 重新读取配置，再 restart 相关服务。只改文件不 reload，systemd 用的还是内存里的旧版本。修改单元文件推荐用 systemctl edit nginx，它会写进 override.conf 而不污染原文件，回滚时删掉这个 override 即可。
systemd 里怎么替代 crontab 做定时任务？
用 systemd timer，它比 cron 更适合需要精确控制、依赖服务状态或要输出日志的任务。systemctl list-timers 列出所有定时任务及下次执行时间；配一个 .service 和同名 .timer 后用 systemctl enable --now <timer> 启用。任务输出进 journalctl -u <service>，比 cron 的邮件通知更好排查。
由 巧匠 维护
公开更新于 2026年7月21日，内容持续校对官方文档。