★ FEATURED ARTICLE 1. 别小看这一章服务管理是 RH124 里最值钱的基础功我这些年带过不少准备 RHCSA 的学员很多人一翻开 RH124 教材就急着去看文件权限、用户管理这些章节觉得“控制服务和守护进程”无非就是几条 systemctl 命令考试前背一背就行。但实际到了考场或者真到生产环境里排查问题时栽跟头最多的恰恰是这一章。为什么因为服务管理不是“记住命令”就能过关的它考验的是你对系统启动流程、进程生命周期、依赖关系、日志定位这套完整逻辑的理解。RH124 第 9 章“控制服务和守护进程”安排在这个位置绝不是随便排的——前面的章节教你认路、开机器、摸文件从这一章开始你才真正让 Linux 系统“跑起来干活”。守护进程这个概念我会跟学员打一个比方守护进程就像是饭馆后厨里一直在岗的师傅。你点菜输入命令师傅们各自负责自己的灶台——有的是蒸饭的有的是炒菜的有的是洗碗的——他们不等着你叫才开工而是系统一开张就各自在位。systemd 就是那个后厨总管负责点名、安排排班、盯谁在偷懒、谁累垮了把它扶起来。理解了这个场景后面所有 systemctl 操作都不会觉得抽象。这篇文章我会完全围绕 RH124 第 9 章的知识点按问答题的节奏把守护进程与服务的概念、systemd 的核心管理命令、单元文件结构、target 机制、日志排查这些内容全部拆开揉碎。适合正在准备 RHCSA 考试的人也适合刚入行、想搞明白服务为什么起不来、怎么设置开机自启的运维新手。2. 守护进程与服务先搞清楚你管的东西到底是什么2.1 守护进程不是“病毒”是系统里的“老黄牛”很多零基础学员第一次听到 daemon 这个词脑子里会浮现出电影里的黑客程序。其实守护进程恰恰是这个星球上最勤劳的程序形态。它的特征是长期驻留内存、不占用终端、在后台默默干活。举几个你天天都在接触的例子。你 ssh 登录一台服务器sshd 这个服务其实早就跑着了它守候在 22 号端口上来一个连接就“生”一个会话进程来处理你访问网页httpd 或 nginx 进程在后台常驻你发邮件postfix 进程监听 25 端口。这些服务如果不在后台我们一关终端它们就退出那服务器啥也干不成。区分几个术语很重要守护进程daemon、服务service、进程process。按照 RH124 的口径守护进程就是后台运行的进程它们通常以“d”结尾比如 systemd、sshd、httpd 里的 httpd 的“d”就是 daemon 的意思。服务是一个更宽泛的概念一个服务可能包含多个进程比如 Apache 服务有主进程和 worker 进程。而我们平时用 systemctl 管理的就是从服务的视角去控制系统里的一组进程。2.2 systemd 凭什么取代了 SysVinitRH124 第 9 章会简单提一句历史RHEL 7 开始系统初始化和服务管理全面切换到 systemd取代了老旧的 SysVinit。这里要理解的是 systemd 的几个关键优势而不是死记年份。老 SysVinit 时代服务管理靠脚本启动服务时必须等上一个脚本完全结束才能启动下一个哪怕两个服务之间没有任何依赖关系也要排队系统启动速度自然慢。systemd 的设计思路改成了并行启动只要服务之间没有明确依赖就同时拉起。另外systemd 引入了“按需启动”机制socket 激活等高级玩法让一些不常用的服务不用着急启动等有人访问时再拉起来就行。这对于服务器开机速度的提升是肉眼可见的。还记得前面那个后厨总管比喻吗SysVinit 像是只有一个厨师长所有菜必须按顺序做systemd 是多个厨师并行操作还能实时监控哪个灶台熄火了立刻重新点火。注意RHCSA 考试不要求你会写 unit 文件但要求你能看懂 unit 文件、能判断服务当前状态、能修改配置让服务按你期望的方式运行。不要上来就啃长篇配置先把管理命令玩熟。2.3 服务状态有几种别被 systemctl 的输出搞晕我观察到一个普遍现象学员敲 systemctl status 命令后看到一大片输出就懵了不知道该看哪一行。systemctl status sshd输出关键要看三块内容第一行是单元描述和加载情况含 show 状态。比如Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: enabled)里面的enabled表示开机自启。第二行是 Active 状态这是最核心的。active (running)是正在运行active (exited)是运行过但当前没有进程驻留比如一次性任务inactive (dead)就是没在跑。后面几行是最近日志用来排查退出原因。我发现一个很容易被忽略的重点loaded不等于active。一个服务已经被 systemd 读取了配置这只能说明“系统知道有这号人”至于这个人现在是在工位上干活还是回家睡觉了要看active。这两个概念混淆是新手排错时经常卡壳的地方。3. systemctl你与系统服务之间的对话窗口3.1 最常用的五个子命令先形成肌肉记忆RH124 第 9 章明确要求掌握 systemctl 的常用子命令。课堂上我要求学员先练出肌肉记忆的就下面这几个systemctl start 服务名 # 立即启动不设开机自启 systemctl stop 服务名 # 立即停止 systemctl restart 服务名 # 停止后重新启动常用于配置修改后 systemctl reload 服务名 # 不中断服务重新加载配置文件 systemctl enable 服务名 # 设置开机自启 systemctl disable 服务名 # 取消开机自启这里必须解释清楚restart和reload的区别这是考试喜欢挖坑的地方也是生产环境操作的“生死线”。restart是粗暴地把进程全部干掉再拉起来服务会有几十毫秒到几秒的不可用时间但如果程序本身不冲突往往能解决很多运行异常。reload是温和地通知进程“配置文件改了你重新读一遍”进程 pid 不变连接不中断。像 nginx、sshd 这样的服务改完配置优先考虑 reload不要动不动就 restart否则线上用户会感受到明显卡顿。还有一对容易混淆的组合start和enable是两个独立操作一个只管当前一个只管开机。很多人以为启动了服务就等于开机自启了这是错的。你start httpd后服务器重启httpd 仍然是死的除非你执行过enable httpd。生产环境里常见的问题——服务器重启后某个服务没起来——根因往往就是当年部署时只 start 没 enable。systemctl enable --now httpd # 开机自启 立即启动一步完成这是我强烈推荐的口诀式命令--now参数把“当前启动”和“开机自启”捆绑执行省掉一次手工 start也少了一个遗忘点。3.2 查看状态别只看“活没活”还要看“想不想活”systemctl status 服务名 systemctl is-active 服务名 # 只回显 active/inactive/failed systemctl is-enabled 服务名 # 只回显 enabled/disabledstatus 命令适合人类读一大片输出里什么都有is-active 和 is-enabled 适合脚本判断输出干净利落。写监控脚本时别去 grep status 的输出直接用这两个命令省心得多。还有几个查看类命令要掌握systemctl list-units --type service --state running列出所有正在运行的服务单元。systemctl list-unit-files --type service列出所有服务单元文件及是否 enable。systemctl list-dependencies 服务名查看服务的依赖树排错时很好用。3.3 一个典型的完整操作流程搭个 HTTP 服务把前面命令串起来走一遍你会对整体逻辑更清晰。假设现在要在一台 RHEL 9 上部署 httpddnf install -y httpd systemctl start httpd systemctl enable httpd systemctl status httpd执行完 status 后大概率你会看到active (running)就放心了。但我要提醒一句systemctl status 显示的“running”只代表进程活着不代表业务可用。极端情况下 Apache 配置写错了进程照样能跑起来但它监听不到真正的端口。所以判断服务是否真正可用一定要配合端口检查。ss -tlnp | grep 80 curl http://localhost这个思路会一直伴随你的运维生涯服务管理命令管的是“进程状态”业务可用性要靠“端口/接口探测”来确认。4. 单元文件与 target理解 systemd 的“规矩”和“关卡”4.1 单元文件优先级同一份配置三个地方放听谁的systemd 里面被管理的对象都叫“单元unit”服务只是其中一种。单元文件存放在三个层级优先级从高到低目录来源优先级/etc/systemd/system管理员自定义或覆盖最高/run/systemd/system运行时生成的临时配置高/usr/lib/systemd/system软件包安装时自带低这个设计非常巧妙。软件包自带的默认配置放在 /usr/lib/systemd/system 里系统升级时可能被覆盖你不能去改它管理员的自定义放在 /etc/systemd/system 里哪怕软件重装也不会被动。生产环境里改服务配置正确姿势是在 /etc/systemd/system 下建一个 override 文件同名 but 带 .d 后缀的目录而不是直接改 /usr/lib 下的原文件。直接改 /usr/lib 下的文件我见过太多人这么干表面上看也能生效但一旦软件包更新你的修改就被新版本覆盖而且不会有人告诉你。想优雅地改某个服务的参数推荐做法是mkdir -p /etc/systemd/system/sshd.service.d cat /etc/systemd/system/sshd.service.d/override.conf EOF [Service] Restartalways RestartSec3s EOF systemctl daemon-reload这样 sshd 服务一旦异常退出systemd 会在 3 秒后自动拉起它。至于为什么不直接在原来的 unit 文件里加Restartalways——上面表格已经解释了那个文件归软件包管轮不到你改。4.2 剖析一个服务单元文件的骨架拿 httpd 的单元文件举例RHEL 9 上可以看到核心结构如下[Unit] DescriptionThe Apache HTTP Server Wantssystemd-networkd.service Afternetwork.target [Service] Typenotify ExecStart/usr/sbin/httpd -DFOREGROUND ExecReload/usr/sbin/httpd -k graceful Restarton-failure [Install] WantedBymulti-user.target课堂上我会让学员按三段来记[Unit]段落记录描述和依赖关系[Service]段落定义怎么启动、怎么重启、以什么类型运行[Install]段落定义 enable 时挂到哪个 target 下面。After和Wants要区分。Wants是软依赖能拉起来就拉起拉不起来不影响本体启动After只决定启动顺序不决定依赖。还有一种是Requires这是硬依赖要求的服务起不来本体也别想起来。这个差异是考试的重点也是排查“A 服务明明配置了依赖 B为什么 B 没启动”时优先怀疑的对象——八成是写成了Wants而不是Requires。Type这个参数也值得琢磨。常见的几种simpleExecStart 指定的进程就是主进程立即认为服务启动完成。forking主进程 fork 出子进程后立即退出父进程退场子进程接管传统 daemon 的做法。notify服务进程主动向 systemd 发通知报告“我准备就绪了”。oneshot执行完即退出的一次性任务。判断 Type 对不对直接影响 systemctl status 显示的状态是否准确。如果 Type 写错systemd 会误判服务启动完成或一直认为没起来定位问题时会走弯路。4.3 target服务启动的“总开关”target 在 RH124 里定义为“一组单元的集合”作用相当于把系统引导过程划分成若干里程碑。你可以理解为关卡节点系统开机时先到某个 target激活这个 target 下面的所有服务然后切换到下一个 target再激活另一批服务。最常用的是这几个multi-user.target纯字符界面的多用户状态服务器默认落到这里。graphical.target带图形界面的状态等于 multi-user 加上图形登录。reboot.target重启。poweroff.target关机。查看当前系统落到了哪个 target用systemctl get-default设置默认 target用systemctl set-default multi-user.target临时切换当前运行级别不需要重启用systemctl isolate multi-user.targetisolate是那个最霸道的命令它会停掉所有不属于目标的单元。所以对服务器做隔离操作前一定确认你自己有控制台访问能力不然可能把自己锁在外面。另外在 RH124 对应的 RHCSA 考试中图形界面机器上改默认 target 到字符界面也是经典操作逻辑就是上面两行命令。每个服务单元文件里的[Install]段写的WantedBymulti-user.target就是告诉 systemd“当你把我 enable 时把我挂到 multi-user.target 的 Wants 列表里”。这样开机进入 multi-user 时系统会自动拉起这个服务。所以 enable 的本质动作是建了一个软链接从/etc/systemd/system/multi-user.target.wants/指到实际的 unit 文件。4.4 修改了单元文件必须重载这是一个极其常见的坑你改了 /etc/systemd/system 下的某服务配置然后 systemctl restart 服务发现配置根本没生效。原因很简单——systemd 还在用内存里缓存的旧配置。改完任何 unit 文件或 override 文件后必须执行systemctl daemon-reload这个命令让 systemd 重新读取磁盘上的 unit 文件。你在很多部署脚本里看到的“restart 之前先 daemon-reload”不是说每次都要做但只要你加了、删了、改了 unit 文件哪怕只是改了个注释也建议执行一次成本极低收益是避免“改了好像没改”的诡异问题。5. 日志管理服务出问题第一步不是猜是查日志5.1 journald集中式日志的集散中心RHEL 7 之后系统的日志收集统一交给了 systemd-journald。它把内核日志、各类服务的标准输出、标准错误、syslog 内容全部收拢起来按服务单元打标签归档。查询服务日志有天然的优势——你根本不用知道日志文件写在哪个路径一条命令全解决journalctl -u sshd这条命令显示 sshd 的全部日志。平时最常用的加料版journalctl -u sshd -f持续跟踪类似 tail -f调试时开着很爽。journalctl -u sshd --since 1 hour ago只看最近一小时的日志。journalctl -u sshd --since today --until 2025-01-01 00:00按时间区间过滤。journalctl -u sshd -p err只看 error 级别以上的日志。配合 -p 可以迅速过滤出关键错误不用在一堆 info 日志里人工翻。5.2 从日志反推服务启动失败的原因我让学员做故障演练时最经典的一幕是某个服务起不来学员先懵三秒然后开始瞎猜什么端口冲突了、防火墙挡了、配置文件错了。正确的路径是先看状态再看日志最后才动手。systemctl status httpd journalctl -u httpd -n 50status输出末尾会自带最近几条日志journalctl -n 50拉最近 50 条。这两步走完八成的原因已经浮出水面了。举一个实际排错例子某次学员把 httpd 的 DocumentRoot 目录权限改成了 700然后 restart 服务状态变成 failed。journalctl 里明确写着类似Permission denied的报错因为 Apache 的 worker 进程以 apache 用户身份运行进不了 root 才拥有的目录。你如果不知道 apache 用户需要什么权限看到这个日志再结合这个小知识点马上就能对症下药。5.3 日志持久化重启不丢数据journald 默认把日志存在内存里服务器一重启之前的日志全没了。生产环境想留痕必须开启持久化存储mkdir -p /var/log/journal systemctl restart systemd-journald目录存在journald 自动切换为持久模式日志会写到磁盘。RH124 考试范围里不深究这个但作为运维基本功建议你现在就知道。不然哪次线上出问题重启以后想复盘发现日志干干净净一片空白那才是真叫天天不应。6. 常见故障与排查实录那些年我们踩过的 systemd 的坑6.1 服务状态是 failed但日志里没有明显报错这类问题往往和“环境”有关。unit 文件里的Environment或环境脚本设置有问题服务进程启动时报错但报错信息没输出到 journald看起来就像“没理由的失败”。排查思路是手动用服务进程的实际身份运行一遍启动命令。比如 httpd 起不来但日志只有一句failed你可以sudo -u apache /usr/sbin/httpd -DFOREGROUND直接在终端跑一遍把错误逼出来。很多时候报错信息会直接打在终端上远比日志里的概括性描述来得具体。这招在排查 systemd 单元启动类问题时效率高得惊人。6.2 systemd 时间同步问题有一次学员在做实验室时发现journalctl --since today一片空白但明明刚才还有日志刷出来。一查系统时间发现 VM 的时钟严重偏离真实时间日志都带着一个“未来时间戳”所以按今天过滤时什么都捞不着。这类问题在生产环境的虚拟机上很容易遇到尤其是从快照恢复的老虚拟机。解决思路是先校准时间再看日志时间轴是否正常。虽然这一章没有专门讲 chrony但日志排查时时间同步的概念一定会撞上提前有个意识能少走弯路。6.3 服务被 killed是内存被 OOM 干掉了你执行 systemctl status 看到进程状态是active (running)但日志里出现Killed字样。这通常是进程因内存不足被内核 OOM Killer 选中干掉了。你会在 journalctl 或 /var/log/messages 里看到内核相关记录。排查思路确认进程实际是不是活着ps -ef | grep 服务名看 pid 是否还在。看内存余量free -h如果 available 很低大概率是内存压力问题。用systemctl status里的 Main PID 和ps -o etime对一下如果进程是从失败后重新拉起的可能已经经过了两次重启循环。这类“状态看着是活其实已经死而复生”的情况是实际生产中最难察觉的伪健康。这也是为什么监控脚本不能只看 systemctl is-active一定要结合业务端口和进程存活时长判断。6.4 开机启动顺序“莫名其妙”如果服务 A 启动依赖服务 B 已经把某个端口准备好但 A 是在 B 之前拉起的就会失败。检查写法时记住After控制顺序它写在 A 的 [Unit] 段里。如果 A 写了AfterBsystemd 会等 B 启动完再启动 A。但After不等同于依赖关系如果你还写了WantsB那 B 挂了 A 照样起。希望 B 挂掉后 A 也别起来需要RequiresB。明确需求量级光是“先后顺序”用 After“一起活、一起死”用 Requires。不要想当然地写。6.5 配置文件有语法错误服务还能起有一种比较隐蔽的情况服务配置错了但进程能跑。比如 sshd_config 里写了一个无效参数sshd 启动时会以“静默忽略”的方式继续运行并不报错。systemctl status 显示 active但你的某项功能死活不对。这时候只有读日志或手动运行主程序才能看到真实的 warning。这类问题比较考验经验我平时教学时反复跟学员强调systemctl 管理的是“进程起没起来”不是“配置对没对”。进程活着代表它按当前配置能自洽运行不保证配置符合你的预期。排查配置类问题直接调出日志或者手动运行并按需求加-t等参数做验证。7. 实操测试自己动手做一遍比看十遍记住得更牢RH124 第 9 章的知识点很适合用一套小实验收尾。以下实验建议你在虚拟机里完整走一遍全部做完大约需要二十分钟但对命令和理解会有质的提升。# 1. 安装 httpd dnf install -y httpd # 2. 启动并设置自启 systemctl start httpd systemctl enable --now httpd # 3. 确认状态 systemctl status httpd # 4. 查看 httpd 的单元文件 systemctl cat httpd # 5. 查看 httpd 的依赖 systemctl list-dependencies httpd # 6. 测试临时关闭自启再恢复 systemctl disable httpd systemctl list-unit-files | grep httpd # 应该是 disabled systemctl enable httpd # 7. 修改配置前先备份修改后 reload cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak systemctl reload sshd # 8. 看日志 journalctl -u httpd -n 20 # 9. 设默认 target 为字符界面再改回来 systemctl set-default multi-user.target systemctl set-default graphical.target做第 7 步时注意reload 对 sshd 的安全性如果你当前正通过 ssh 连接且 sshd_config 改错了reload 不会断开现有连接但新连接会连不上。所以改完立刻新开一个终端测一下能不能登录能登录再继续用不能就赶紧用现有连接把备份文件还原。我还建议你把 httpd 的 unit 文件复制到 /etc/systemd/system/ 下改改Restartalways然后 kill 掉主进程观察 systemd 在几秒内自动把它拉起来。kill -9 $(pgrep httpd | head -1) systemctl status 服务名 # 过几秒再看状态是 active这比单纯敲命令更能建立对“守护进程”这个词的体感——你现在亲手杀掉了它它又活了这就是 systemd 守护进程的真正含义。8. 经验篇RH124 第 9 章你该怎么学才算真学透判断一个人是不是真掌握这一章我通常看三个维度第一会不会根据“服务起不来”这一个现象梳理出排查顺序。顺序是状态 → 日志 → 配置 → 端口 → 测试。这个顺序不是教材里写的是生产环境压出来的经验建议你自己写一个 checklist 贴在工位上。第二会不会意识到 status 输出里的“Loaded”和“Active”是两回事。很多人一看 loaded 就默认服务没问题这是最大的盲区。第三会不会合理选择 restart 和 reload。改配置先 reload程序异常再 restart这不仅是命令选择问题更是对线上业务的负责态度。我见过因为图省事一律 restart 的服务把线上会话全部打断用户在群里骂了半天。从那天起我就形成了一个习惯任何服务配置变更第一选择永远是 reload。另外学这一章时建议打开一个免费的系统虚拟机一起操作不要只看不练。键盘敲命令和眼睛看教程完全是两回事敲过一遍systemctl enable --now后你的肌肉记忆会帮你把它刻在脑子里。RH124 第 9 章是整个 RHCSA 认证体系里服务和进程管理的地基。后面你会学网络配置、存储管理、SELinux这些内容多多少少都要和服务打交道。把 systemd 的逻辑吃透你后面遇到的多半只是“命令变化”而不是“思路重来”。最后分享一个小技巧遇到不认识的新服务先执行systemctl cat 服务名看它的 unit 文件再执行journalctl -u 服务名 --since today看它今天的日志。只需要这两条命令你就大致知道这个服务是干什么的、跑得正不正常。这招在接手一台陌生服务器时特别好用推荐你用起来。
阅读完成 · 觉得有帮助？
