跳转到内容
搜索 Rocky Linux 文档

    浏览当前文档目录

    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)。

    先建立三个概念上的区分:

    • 单元与目标:服务只是 systemd 管理对象中的一类;系统走到哪个状态由目标决定,所以要分清「服务没起来」与「根本没有请求到这个目标」;
    • 依赖表达的是顺序与需要:依赖关系写对不保证服务一定能起来,写错却足以让它永远起不来;改依赖前先想清楚是谁需要谁;
    • 定义是声明式的:改动单元定义之后要让 systemd 重新加载配置,而不是指望正在运行的进程自己感知到变化。

    再把三个视角对应到三章上:

    • 进程视角:服务启动失败的常见形态是进程在很短时间内退出——先确认它有没有真正运行过,再谈配置;
    • 日志视角:退出原因的第一手材料在日志里,而不在配置文件里;先读原文,再决定改什么;
    • 时间视角:周期性动作与时间同步异常会让问题只在特定时刻出现,这类「偶发」往往有明确的时间规律。

    排查顺序:先分清是哪一层出问题

    Section titled “排查顺序:先分清是哪一层出问题”

    服务问题按下面五步推进,每一步先得到结论再进入下一步:

    1. 状态:先确认服务在 systemd 眼中的状态,以及它是否被请求启动过;
    2. 依赖:确认它需要的东西是否已经就绪——网络、挂载、其它服务;
    3. 资源:确认内存、文件描述符、进程数一类限制是否在启动瞬间就把它挡住了;
    4. 日志:读它给出的退出原因与时间线,再和「最后一次正常」做对比;
    5. 回退点:动手改之前先记录当前配置与可回退的状态,避免把可恢复的问题拖成不可恢复。