Rocky Linux 服务与 systemd 运维
服务「不按预期启动」时，最容易犯的错是直接钻进服务配置里找问题。更省时间的顺序是：先确认 systemd 眼中的状态，再看它依赖的东西到齐没有，最后回到日志里读它自己给出的原因。本页给出 Rocky 官方文档在这几个方向上的入口，以及配套的排查顺序。
systemd 专章：服务与单元管理的官方入口
Section titled “systemd 专章：服务与单元管理的官方入口”官方 Admin Guide 含 systemd 专章（16-about-sytemd），涵盖服务与单元管理；本轮核对日为 2026-10-12。
进程、日志与计划任务：三章日常基线
Section titled “进程、日志与计划任务：三章日常基线”官方 Admin Guide 另设进程（08-process）、日志（17-log）与计划任务（11-tasks）专章，与 systemd 专章一起构成日常运维基线。
定时任务与时间同步：自动化指南的对应篇目
Section titled “定时任务与时间同步：自动化指南的对应篇目”官方自动化指南覆盖 cron（cron_jobs_howto 与 cronie 两篇）、anacron、chrony 时间同步与 OliveTin，另有 Packer 与 vSphere 的模板自动化，以及 Ansible 学习书（books/learning_ansible）。
从官方章节到排查方向
Section titled “从官方章节到排查方向”先建立三个概念上的区分：
- 单元与目标：服务只是 systemd 管理对象中的一类；系统走到哪个状态由目标决定，所以要分清「服务没起来」与「根本没有请求到这个目标」；
- 依赖表达的是顺序与需要：依赖关系写对不保证服务一定能起来，写错却足以让它永远起不来；改依赖前先想清楚是谁需要谁；
- 定义是声明式的：改动单元定义之后要让 systemd 重新加载配置，而不是指望正在运行的进程自己感知到变化。
再把三个视角对应到三章上：
- 进程视角：服务启动失败的常见形态是进程在很短时间内退出——先确认它有没有真正运行过，再谈配置；
- 日志视角：退出原因的第一手材料在日志里，而不在配置文件里；先读原文，再决定改什么；
- 时间视角：周期性动作与时间同步异常会让问题只在特定时刻出现，这类「偶发」往往有明确的时间规律。
排查顺序：先分清是哪一层出问题
Section titled “排查顺序：先分清是哪一层出问题”服务问题按下面五步推进，每一步先得到结论再进入下一步：
- 状态：先确认服务在 systemd 眼中的状态，以及它是否被请求启动过；
- 依赖：确认它需要的东西是否已经就绪——网络、挂载、其它服务；
- 资源：确认内存、文件描述符、进程数一类限制是否在启动瞬间就把它挡住了；
- 日志：读它给出的退出原因与时间线，再和「最后一次正常」做对比；
- 回退点：动手改之前先记录当前配置与可回退的状态，避免把可恢复的问题拖成不可恢复。
- Rocky 启动故障排障 — 机器根本起不来时的分层定位
- Rocky 自动化与配置管理 — 把定时任务纳入批量交付
- Rocky 安全基线加固 — 服务面收敛与安全更新
- Rocky 合规基线（CIS 思路） — 审计与日志留存
- 服务器基线 — 新机上线检查清单
- 官方：Admin Guide 的 systemd 章