RH124 系列总结写到第八篇正好到了一道分水岭。前面围绕文件、用户、权限、进程的这几个单元学的时候会很有成就感命令背了一堆但真正放到一台真实服务器上你会发现这些知识其实是散落的零件。第八课在 Red Hat 官方 RH124 课程里的标准主题是“使用 systemd 控制服务和守护进程”它第一次把零件拼成了机器服务的启动、停止、开机自启、依赖关系、故障日志全部落到 systemd 这套机制里。学到这里你才算是开始管理 Linux 系统而不只是在 Linux 里敲命令。这篇总结适合两类人一类是正在自学或者备考 RHCSA 的同学另一类是想把 systemd 和网络排查逻辑系统捋一遍的运维新人。1. 第八课在课程里的角色从“命令手感”切换到“系统机制”1.1 前七个单元到底在铺垫什么RH124 的前半程基本上是在解决“这台机器长什么样”的问题。命令行访问教会你登录和导航文件管理让你知道数据放在哪里用户和组解决的是身份问题权限解决的是访问边界进程管理告诉你系统里有哪些东西在跑。这些内容学完之后你会发现自己能读懂一台服务器的大多数常规状态也能处理很多琐碎问题——某个文件权限不对某个进程占着 CPU某个用户登录不了。但这些操作都有一个共同特点它们是点状的。你操作的是某个具体的对象而不是对象背后的运行机制。第八课的转折点就在这里它不再问“这个文件属于谁”而是问“这个程序是怎么被系统拉起来并且一直活着的”。当一台服务器重启之后某些服务会自动出现某些不会这背后的规则是什么定时任务、网络服务、数据库、Web 服务它们各自什么时候启动、依赖什么前置条件、崩了之后系统会做什么——这些问题的答案全部集中在 systemd 这一层。所以我的建议是学这一课之前最好把第六课“监控和管理进程”翻一遍。如果你还不熟悉ps、top、kill这些命令直接学 systemd 会有点悬空。因为服务本质上是“被系统看护的特殊进程”进程概念不牢服务状态就很难理解透彻。1.2 这门课的官方考核边界在哪很多人学着学着会把 RH124 想得太深其实第八课在 RHCSA 考试里的边界是很明确的。你需要掌握的操作基本可以列成一张清单启动、停止、重启、重载一个服务设置服务开机自启或者强制它不要自启查看服务的当前状态和基本信息查看并分析服务的运行日志修改服务配置后知道该用 reload 还是 restart理解 unit 文件的基本结构能读懂开机依赖关系。不需要你徒手写一个复杂的 unit 文件也不需要你去研究 cgroup 的深层实现更不需要你把 systemd 源码看明白。考试要的是在规定动作内熟练不是研究深度。但这里有一个容易踩的思维误区很多初学者以为“会背 systemctl 命令”就够了实际上 RH124 第八课真正考的是判断力。给你一个场景某服务启动失败你要能根据日志判断是配置文件写错了、端口被占了、还是依赖的服务没起来。这种题目基本不会以“请写出 systemctl restart 的完整命令”这种形式出现而是给你一个故障现场要求你把服务恢复并设置开机自启。命令只是工具判断才是核心。1.3 与后续单元的分工RH124 后面还会单独讲到网络配置、日志分析、SELinux、软件包管理这些内容但第八课不是孤立存在的。我自己学到后面才发现service 管理其实是很多后续内容的地基。网络服务起不来根因可能在 NetworkManager 配置SELinux 拦截了进程表面上看是服务状态异常。学习的时候最好带着一个想法所有状态异常最终都能在手动的命令操作里找到线索。带着这个思路后面几课几乎不用背靠排查就能把知识串起来。2. unit 文件与服务生命周期一个真实的 systemctl 全景2.1 用一个实际服务拆解 unit 文件三段要理解 systemd不能只看命令得先看 unit 文件。RHEL 9 上以 sshd 为例你可以用下面这条命令查看它的完整定义systemctl cat sshd.service执行结果通常包含三个段落每一段的职责不一样[Unit]描述这个服务的基本信息和依赖关系包括说明文档、依赖哪些服务、在什么之后启动[Service]定义如何启动进程包括启动命令、进程类型、如果崩了是否重启、以什么身份运行[Install]定义这个服务在什么 target 下被启用也就是开机自启的挂载点。以 sshd 为例[Service]段里会有ExecStart/usr/sbin/sshd -D $OPTIONS意思是前台方式运行 sshd由 systemd 直接看护。还有Restarton-failure表示只有异常退出才自动拉起正常退出不拉。这个细节非常关键——很多人自定义服务时喜欢无脑写Restartalways结果服务被自己手动停掉之后马上又被拉起来反而造成困惑。再看[Install]段正常会写WantedBymulti-user.target。这句话的直译是这个服务想要被挂在 multi-user.target 下面。你执行systemctl enable sshd实际做的就是在 multi-user.target.wants 目录里创建一个指向 sshd.service 的软链接。理解这一层之后enable 这个动作对你来说就不再是魔法了。2.2 服务生命周期的命令速查第八课的核心操作我习惯分成三组来记状态查询组systemctl status sshd.service systemctl is-active sshd.service systemctl is-enabled sshd.servicestatus会输出详细信息包括是否在运行、主进程号、最近日志适合排查。is-active和is-enabled只返回 active/inactive、enabled/disabled适合写脚本和快速判断输出干净。操作组systemctl start sshd.service systemctl stop sshd.service systemctl restart sshd.service systemctl reload sshd.service这里必须讲清楚 restart 和 reload 的差别。restart 是先把进程杀掉再重新拉起如果这个服务有在跑的业务连接所有连接都会中断reload 则是让服务自己重新读取配置文件不中断业务。并非所有服务都支持 reload支持的 service 会在 unit 文件里写ExecReload。日常修改配置文件时优先尝试 reload不行再 restart这是一个好习惯。开机自启组systemctl enable sshd.service systemctl disable sshd.service systemctl mask sshd.service systemctl unmask sshd.serviceenable 和 mask 是很多人搞混的重灾区。enable/disable 只是控制开机自启服务本身依然可以被手动 startmask 则更狠它会把服务彻底锁死连手动启动都不行单元文件被软链接到 /dev/null。mask 一般用于“这个服务我不允许任何人启动”的场景比如安全加固时禁掉一些不必要的服务。考试里如果只说“禁止开机自启”用 disable 就够千万别顺手 mask反过来题目明确说“必须无法启动”再考虑 mask。2.3 大多数人忽略的 daemon-reload修改了 unit 文件之后很多人直接执行 restart发现没生效于是开始怀疑配置写错了。真相往往是systemd 还在用旧的内存状态根本没有重新读取磁盘上的文件。修改 unit 文件之后第一件事是执行systemctl daemon-reload这个动作会重新加载 systemd 管理的所有 unit 定义。哪怕你只是改了一个字段这步也不能省。我的习惯是改完任何 unit 文件立刻 reload然后再 restart 对应服务。顺序错了后面排查的时间往往远超你当时省下来的一秒钟。注意修改的是/etc/systemd/system/下自定义的 unit 文件或者/usr/lib/systemd/system/里随软件包安装的默认模板都要执行 daemon-reload。区别在于前者是你自己写的后者一般不建议直接改最好是创建 override 文件覆盖字段但这是更深一层的内容RH124 阶段先记住 daemon-reload 别再忘。2.4 自定义一个简单的服务RH124 第八课通常还会要求你能够创建一个简单的服务。我以 Nginx 的安装包服务为例如果你从 EPEL 装的 Nginx官方其实已经带好了 unit 文件但为了理解机制完全可以自己写一个最小例[Unit] DescriptionMy Test Daemon Afternetwork.target [Service] ExecStart/usr/local/bin/mytestd Restarton-failure Usertestuser [Install] WantedBymulti-user.target把这个文件放到/etc/systemd/system/mytestd.service执行systemctl daemon-reload然后systemctl enable --now mytestd.service就能把启用和启动一次做完。这里--now这个参数值得养成习惯它能把两步合并减少你在两个命令之间漏掉一次的概率。3. 依赖、目标与日志服务之间的协作和翻车现场3.1 Wants、Requires、After 到底谁说了算很多 unit 文件的[Unit]段会写Afternetwork.target甚至有Wants、Requires这些字段的语义差别必须掰清楚Wants弱依赖。启动这个服务之前尽量把列出的服务也启动但失败也无所谓不影响主服务Requires强依赖。列出的服务如果启动失败主服务也会被停止或者根本启动不了After只规定启动顺序不规定依赖关系。意思是“等前面的服务已经启动之后再启动我”Before与 After 相反先启动自己再启动后面列出的服务。判断优先级时记住一个口诀After/Before 管顺序Wants/Requires 管成败。两套机制并行不悖既可以说“我需要数据库”又可以说“我要等数据库就绪后再自己启动”。实际写单元文件时最常见的搭配是Requiresxxx.service加上Afterxxx.service单一字段无法完全表达“必须依赖且后启动”。3.2 target 其实就是一叠服务清单target 在 RH124 第八课里是个绕不开的概念。你不必把每个 target 都背下来但要理解它和 SysVinit 里的 runlevel 是对应关系。RHEL 常见的映射target大致作用poweroff.target关机rescue.target单用户救援模式multi-user.target多用户文本模式大部分服务器的目标graphical.target图形界面依赖 multi-user.targetreboot.target重启执行systemctl get-default可以查看当前默认启动目标改默认目标用systemctl set-default multi-user.target。服务器上一般就是 multi-user如果你装了图形桌面并且希望开机进图形才需要切到 graphical。理解 target 的最大价值在于看懂开机过程系统启动时内核把控制权交给 systemdPID 1systemd 启动默认 target而 target 内部通过Wants和After把该启动的服务全部拉起来。你在systemctl enable一个服务时本质就是把它挂到某个 target 的 wants 目录里。所以故障排查时如果某服务明明 enable 了开机却不自启去检查它挂载的 target 是否还在多数问题都出在这里。3.3 journalctl别再只知道 tail /var/log/messagesRH124 到第八课这个阶段日志排查是一个隐性考点。传统习惯是tail -f /var/log/messages但在 RHEL 7 之后的系统上更推荐直接使用journalctl因为它能直接和 unit 关联起来看。先记住几个最常用的组合journalctl -u sshd.service journalctl -u sshd.service --since 10 minutes ago journalctl -u sshd.service -f journalctl -u sshd.service -p err第一条命令列出一个服务的全部日志第二条限定时间范围第三条实时跟踪第四条只看 error 以上级别的日志。查服务起不来的原因我的路径通常是先journalctl -u 服务名 -p err --since 1 hour ago看有没有明显报错如果没有再去掉-p err看完整输出。因为有些关键提示其实以 warning 甚至 info 级别输出过滤太狠反而会漏掉线索。journald 默认日志是存在内存里的重启后消失。想持久化保存需要创建/var/log/journal目录并确保属主是 root:systemd-journal然后重启 systemd-journald。这一步 RH124 不一定考但如果你要拿它做实验记录迟早会需要。3.4 systemctl list-units 的状态解读排查时经常要看“系统里到底有哪些服务处于异常状态”一条命令就能扫全局systemctl list-units --typeservice --statefailed如果这条命令返回空说明没有服务处于失败状态。systemctl list-unit-files --stateenabled则能列出所有开机自启的服务。这两个视角配合基本可以回答“这台机器有哪些服务在跑、哪些开机自启、哪些挂了”这三个问题。4. 服务起不来先查网络和端口第八课最常见的连坐问题4.1 为什么学服务管理要顺带复习网络严格来说RH124 把网络配置放到更靠后的单元但我不建议按部就班地完全割裂来学。第八课里大量实验对象是网络服务——sshd、httpd、vsftpd 之类这些服务启动成功只代表进程活了不代表你就能连上。真正判断“服务 OK”需要同时确认三件事进程在运行、端口在监听、防火墙放行了。很多人在这一步被卡住systemctl start httpd成功了但浏览器访问失败于是回到第八课的服务管理里去翻怎么翻都翻不出问题。其实问题根本不在 systemd而在网络层面。4.2 用 nmcli 完成 30 秒静态 IP 配置在 RHEL 系上图形界面用小工具nmtui命令行环境用nmcli。即使在备考阶段我也建议直接用 nmcli 练习因为考试环境基本都是纯命令行。配置静态地址的四步套路我原样写一遍。假设网卡叫ens160要配成 192.168.1.100/24网关 192.168.1.1DNS 用 223.5.5.5命令如下nmcli con mod ens160 ipv4.addresses 192.168.1.100/24 nmcli con mod ens160 ipv4.gateway 192.168.1.1 nmcli con mod ens160 ipv4.dns 223.5.5.5 nmcli con mod ens160 ipv4.method manual nmcli con up ens160前四条命令都在修改配置文件直到最后一条nmcli con up才是让配置生效。这个顺序不要乱。如果是从 DHCP 改成静态第一次做完后ip addr show ens160只看到旧地址不用慌仔细检查是否执行了con up。还有一个高频坑把ipv4.method manual改完之后DHCP 没关干净系统重启后又拿到了 DHCP 地址。解决办法就是确认 method 是 manual而不是 auto。4.3 端口、连接与防火墙 30 秒快速判断配置完地址后判断服务是否能被外部访问常规三步走ss -tlnp | grep 80 curl -I http://127.0.0.1/ systemctl status firewalldss -tlnp看端口是否真的在监听如果在监听但访问失败问题在防火墙或 SELinux。firewall-cmd --list-all能看放行规则添加端口用firewall-cmd --permanent --add-servicehttp firewall-cmd --reload第八课阶段不要求你把防火墙玩得很深但至少要建立这个排查顺序先确认进程活再确认端口通再确认防火墙放行最后再考虑 SELinux。90% 的服务无法访问问题都被这四步覆盖其中至少有一半出在防火墙和 SELinux进程本身根本没问题。5. 备考与实操我建议的第八课练习方法和踩坑记录5.1 一个 15 分钟就能完成的验证流程书本知识学完不动手等于没学。我给自己定的练习流程很简单每次大约 15 分钟专治“看得懂、敲不出来”的毛病。选一个服务比如 sshd停掉它systemctl stop sshd用systemctl is-active sshd确认状态尝试连接一台远程机器发现连不上验证停止效果真实生效启动它再确认能重新连上执行systemctl disable sshd然后重启系统确认开机后没有自启执行systemctl enable sshd再重启确认服务回来了整个过程结束后用systemctl status sshd和journalctl -u sshd -n 20留下记录。整个过程不需要复杂环境一台虚拟机就够。关键是最后要能用自己的话解释出“为什么步骤 5 之后重启服务没起来”如果解释不出来说明还没有真正理解 unit 文件和 target 的关系。5.2 考试里最容易丢分的三个点第一个是restart 和 reload 的选择。考题经常说“修改了配置文件请让配置生效且不影响业务”如果你写 restart即使服务起来了严格意义上也不符合题意因为连接被中断了。优先 reload 的语义才是题目要的。第二个是enable 后没有 start。有人执行了systemctl enable httpd然后立刻问为什么现在访问不了因为 enable 只管开机自启不管当前状态。想一条命令同时搞定用enable --now但你要理解它等价于 enable 再 start。第三个是mask 滥用。做安全加固相关题目时需求往往只是“开机不要启动”很多人为了保险直接 mask结果后续步骤里服务怎么都启动不了反过来怀疑系统坏了。mask 是锁死不是简单禁止自启用之前想清楚。5.3 超出考试范围的几个实用意识学完第八课之后我建议你把研究的边界稍微再往外推一层但不要陷进去。比如systemd-analyze blame可以看开机时每个服务的耗时systemd-analyze critical-chain可以看哪条启动链路最慢。这些命令对优化启动速度很有帮助也是把第八课知识延伸出去很自然的方向。另外在真实服务器上做任何操作之前养成交替确认的习惯启动服务前看一遍配置文件语法重载服务前确认配置文件路径重启系统前确认默认 target 正确。RH124 第八课教给你的是一套“服务控制”的门路但真正值钱的是这套门路变成肌肉记忆之后你在故障现场不用翻文档也能冷静排查的状态。写到这里我自己的体会是学 systemd 这一课最忌讳的就是只背命令不拆 unit 文件只要把 unit 文件看明白后面所有 systemctl 操作都是在和一段明文配置打交道。建议你今天就拿一台虚拟机把 sshd 或者 httpd 的 unit 文件打开逐个字段读一遍再按上面的流程完整跑一轮比盯着课程 PPT 看两个小时有用得多。
RH124 系列总结写到第八篇正好到了一道分水岭。前面围绕文件、用户、权限、进程的这几个单元学的时候会很有成就感命令背了一堆但真正放到一台真实服务器上你会发现这些知识其实是散落的零件。第八课在 Red Hat 官方 RH124 课程里的标准主题是“使用 systemd 控制服务和守护进程”它第一次把零件拼成了机器服务的启动、停止、开机自启、依赖关系、故障日志全部落到 systemd 这套机制里。学到这里你才算是开始管理 Linux 系统而不只是在 Linux 里敲命令。这篇总结适合两类人一类是正在自学或者备考 RHCSA 的同学另一类是想把 systemd 和网络排查逻辑系统捋一遍的运维新人。1. 第八课在课程里的角色从“命令手感”切换到“系统机制”1.1 前七个单元到底在铺垫什么RH124 的前半程基本上是在解决“这台机器长什么样”的问题。命令行访问教会你登录和导航文件管理让你知道数据放在哪里用户和组解决的是身份问题权限解决的是访问边界进程管理告诉你系统里有哪些东西在跑。这些内容学完之后你会发现自己能读懂一台服务器的大多数常规状态也能处理很多琐碎问题——某个文件权限不对某个进程占着 CPU某个用户登录不了。但这些操作都有一个共同特点它们是点状的。你操作的是某个具体的对象而不是对象背后的运行机制。第八课的转折点就在这里它不再问“这个文件属于谁”而是问“这个程序是怎么被系统拉起来并且一直活着的”。当一台服务器重启之后某些服务会自动出现某些不会这背后的规则是什么定时任务、网络服务、数据库、Web 服务它们各自什么时候启动、依赖什么前置条件、崩了之后系统会做什么——这些问题的答案全部集中在 systemd 这一层。所以我的建议是学这一课之前最好把第六课“监控和管理进程”翻一遍。如果你还不熟悉ps、top、kill这些命令直接学 systemd 会有点悬空。因为服务本质上是“被系统看护的特殊进程”进程概念不牢服务状态就很难理解透彻。1.2 这门课的官方考核边界在哪很多人学着学着会把 RH124 想得太深其实第八课在 RHCSA 考试里的边界是很明确的。你需要掌握的操作基本可以列成一张清单启动、停止、重启、重载一个服务设置服务开机自启或者强制它不要自启查看服务的当前状态和基本信息查看并分析服务的运行日志修改服务配置后知道该用 reload 还是 restart理解 unit 文件的基本结构能读懂开机依赖关系。不需要你徒手写一个复杂的 unit 文件也不需要你去研究 cgroup 的深层实现更不需要你把 systemd 源码看明白。考试要的是在规定动作内熟练不是研究深度。但这里有一个容易踩的思维误区很多初学者以为“会背 systemctl 命令”就够了实际上 RH124 第八课真正考的是判断力。给你一个场景某服务启动失败你要能根据日志判断是配置文件写错了、端口被占了、还是依赖的服务没起来。这种题目基本不会以“请写出 systemctl restart 的完整命令”这种形式出现而是给你一个故障现场要求你把服务恢复并设置开机自启。命令只是工具判断才是核心。1.3 与后续单元的分工RH124 后面还会单独讲到网络配置、日志分析、SELinux、软件包管理这些内容但第八课不是孤立存在的。我自己学到后面才发现service 管理其实是很多后续内容的地基。网络服务起不来根因可能在 NetworkManager 配置SELinux 拦截了进程表面上看是服务状态异常。学习的时候最好带着一个想法所有状态异常最终都能在手动的命令操作里找到线索。带着这个思路后面几课几乎不用背靠排查就能把知识串起来。2. unit 文件与服务生命周期一个真实的 systemctl 全景2.1 用一个实际服务拆解 unit 文件三段要理解 systemd不能只看命令得先看 unit 文件。RHEL 9 上以 sshd 为例你可以用下面这条命令查看它的完整定义systemctl cat sshd.service执行结果通常包含三个段落每一段的职责不一样[Unit]描述这个服务的基本信息和依赖关系包括说明文档、依赖哪些服务、在什么之后启动[Service]定义如何启动进程包括启动命令、进程类型、如果崩了是否重启、以什么身份运行[Install]定义这个服务在什么 target 下被启用也就是开机自启的挂载点。以 sshd 为例[Service]段里会有ExecStart/usr/sbin/sshd -D $OPTIONS意思是前台方式运行 sshd由 systemd 直接看护。还有Restarton-failure表示只有异常退出才自动拉起正常退出不拉。这个细节非常关键——很多人自定义服务时喜欢无脑写Restartalways结果服务被自己手动停掉之后马上又被拉起来反而造成困惑。再看[Install]段正常会写WantedBymulti-user.target。这句话的直译是这个服务想要被挂在 multi-user.target 下面。你执行systemctl enable sshd实际做的就是在 multi-user.target.wants 目录里创建一个指向 sshd.service 的软链接。理解这一层之后enable 这个动作对你来说就不再是魔法了。2.2 服务生命周期的命令速查第八课的核心操作我习惯分成三组来记状态查询组systemctl status sshd.service systemctl is-active sshd.service systemctl is-enabled sshd.servicestatus会输出详细信息包括是否在运行、主进程号、最近日志适合排查。is-active和is-enabled只返回 active/inactive、enabled/disabled适合写脚本和快速判断输出干净。操作组systemctl start sshd.service systemctl stop sshd.service systemctl restart sshd.service systemctl reload sshd.service这里必须讲清楚 restart 和 reload 的差别。restart 是先把进程杀掉再重新拉起如果这个服务有在跑的业务连接所有连接都会中断reload 则是让服务自己重新读取配置文件不中断业务。并非所有服务都支持 reload支持的 service 会在 unit 文件里写ExecReload。日常修改配置文件时优先尝试 reload不行再 restart这是一个好习惯。开机自启组systemctl enable sshd.service systemctl disable sshd.service systemctl mask sshd.service systemctl unmask sshd.serviceenable 和 mask 是很多人搞混的重灾区。enable/disable 只是控制开机自启服务本身依然可以被手动 startmask 则更狠它会把服务彻底锁死连手动启动都不行单元文件被软链接到 /dev/null。mask 一般用于“这个服务我不允许任何人启动”的场景比如安全加固时禁掉一些不必要的服务。考试里如果只说“禁止开机自启”用 disable 就够千万别顺手 mask反过来题目明确说“必须无法启动”再考虑 mask。2.3 大多数人忽略的 daemon-reload修改了 unit 文件之后很多人直接执行 restart发现没生效于是开始怀疑配置写错了。真相往往是systemd 还在用旧的内存状态根本没有重新读取磁盘上的文件。修改 unit 文件之后第一件事是执行systemctl daemon-reload这个动作会重新加载 systemd 管理的所有 unit 定义。哪怕你只是改了一个字段这步也不能省。我的习惯是改完任何 unit 文件立刻 reload然后再 restart 对应服务。顺序错了后面排查的时间往往远超你当时省下来的一秒钟。注意修改的是/etc/systemd/system/下自定义的 unit 文件或者/usr/lib/systemd/system/里随软件包安装的默认模板都要执行 daemon-reload。区别在于前者是你自己写的后者一般不建议直接改最好是创建 override 文件覆盖字段但这是更深一层的内容RH124 阶段先记住 daemon-reload 别再忘。2.4 自定义一个简单的服务RH124 第八课通常还会要求你能够创建一个简单的服务。我以 Nginx 的安装包服务为例如果你从 EPEL 装的 Nginx官方其实已经带好了 unit 文件但为了理解机制完全可以自己写一个最小例[Unit] DescriptionMy Test Daemon Afternetwork.target [Service] ExecStart/usr/local/bin/mytestd Restarton-failure Usertestuser [Install] WantedBymulti-user.target把这个文件放到/etc/systemd/system/mytestd.service执行systemctl daemon-reload然后systemctl enable --now mytestd.service就能把启用和启动一次做完。这里--now这个参数值得养成习惯它能把两步合并减少你在两个命令之间漏掉一次的概率。3. 依赖、目标与日志服务之间的协作和翻车现场3.1 Wants、Requires、After 到底谁说了算很多 unit 文件的[Unit]段会写Afternetwork.target甚至有Wants、Requires这些字段的语义差别必须掰清楚Wants弱依赖。启动这个服务之前尽量把列出的服务也启动但失败也无所谓不影响主服务Requires强依赖。列出的服务如果启动失败主服务也会被停止或者根本启动不了After只规定启动顺序不规定依赖关系。意思是“等前面的服务已经启动之后再启动我”Before与 After 相反先启动自己再启动后面列出的服务。判断优先级时记住一个口诀After/Before 管顺序Wants/Requires 管成败。两套机制并行不悖既可以说“我需要数据库”又可以说“我要等数据库就绪后再自己启动”。实际写单元文件时最常见的搭配是Requiresxxx.service加上Afterxxx.service单一字段无法完全表达“必须依赖且后启动”。3.2 target 其实就是一叠服务清单target 在 RH124 第八课里是个绕不开的概念。你不必把每个 target 都背下来但要理解它和 SysVinit 里的 runlevel 是对应关系。RHEL 常见的映射target大致作用poweroff.target关机rescue.target单用户救援模式multi-user.target多用户文本模式大部分服务器的目标graphical.target图形界面依赖 multi-user.targetreboot.target重启执行systemctl get-default可以查看当前默认启动目标改默认目标用systemctl set-default multi-user.target。服务器上一般就是 multi-user如果你装了图形桌面并且希望开机进图形才需要切到 graphical。理解 target 的最大价值在于看懂开机过程系统启动时内核把控制权交给 systemdPID 1systemd 启动默认 target而 target 内部通过Wants和After把该启动的服务全部拉起来。你在systemctl enable一个服务时本质就是把它挂到某个 target 的 wants 目录里。所以故障排查时如果某服务明明 enable 了开机却不自启去检查它挂载的 target 是否还在多数问题都出在这里。3.3 journalctl别再只知道 tail /var/log/messagesRH124 到第八课这个阶段日志排查是一个隐性考点。传统习惯是tail -f /var/log/messages但在 RHEL 7 之后的系统上更推荐直接使用journalctl因为它能直接和 unit 关联起来看。先记住几个最常用的组合journalctl -u sshd.service journalctl -u sshd.service --since 10 minutes ago journalctl -u sshd.service -f journalctl -u sshd.service -p err第一条命令列出一个服务的全部日志第二条限定时间范围第三条实时跟踪第四条只看 error 以上级别的日志。查服务起不来的原因我的路径通常是先journalctl -u 服务名 -p err --since 1 hour ago看有没有明显报错如果没有再去掉-p err看完整输出。因为有些关键提示其实以 warning 甚至 info 级别输出过滤太狠反而会漏掉线索。journald 默认日志是存在内存里的重启后消失。想持久化保存需要创建/var/log/journal目录并确保属主是 root:systemd-journal然后重启 systemd-journald。这一步 RH124 不一定考但如果你要拿它做实验记录迟早会需要。3.4 systemctl list-units 的状态解读排查时经常要看“系统里到底有哪些服务处于异常状态”一条命令就能扫全局systemctl list-units --typeservice --statefailed如果这条命令返回空说明没有服务处于失败状态。systemctl list-unit-files --stateenabled则能列出所有开机自启的服务。这两个视角配合基本可以回答“这台机器有哪些服务在跑、哪些开机自启、哪些挂了”这三个问题。4. 服务起不来先查网络和端口第八课最常见的连坐问题4.1 为什么学服务管理要顺带复习网络严格来说RH124 把网络配置放到更靠后的单元但我不建议按部就班地完全割裂来学。第八课里大量实验对象是网络服务——sshd、httpd、vsftpd 之类这些服务启动成功只代表进程活了不代表你就能连上。真正判断“服务 OK”需要同时确认三件事进程在运行、端口在监听、防火墙放行了。很多人在这一步被卡住systemctl start httpd成功了但浏览器访问失败于是回到第八课的服务管理里去翻怎么翻都翻不出问题。其实问题根本不在 systemd而在网络层面。4.2 用 nmcli 完成 30 秒静态 IP 配置在 RHEL 系上图形界面用小工具nmtui命令行环境用nmcli。即使在备考阶段我也建议直接用 nmcli 练习因为考试环境基本都是纯命令行。配置静态地址的四步套路我原样写一遍。假设网卡叫ens160要配成 192.168.1.100/24网关 192.168.1.1DNS 用 223.5.5.5命令如下nmcli con mod ens160 ipv4.addresses 192.168.1.100/24 nmcli con mod ens160 ipv4.gateway 192.168.1.1 nmcli con mod ens160 ipv4.dns 223.5.5.5 nmcli con mod ens160 ipv4.method manual nmcli con up ens160前四条命令都在修改配置文件直到最后一条nmcli con up才是让配置生效。这个顺序不要乱。如果是从 DHCP 改成静态第一次做完后ip addr show ens160只看到旧地址不用慌仔细检查是否执行了con up。还有一个高频坑把ipv4.method manual改完之后DHCP 没关干净系统重启后又拿到了 DHCP 地址。解决办法就是确认 method 是 manual而不是 auto。4.3 端口、连接与防火墙 30 秒快速判断配置完地址后判断服务是否能被外部访问常规三步走ss -tlnp | grep 80 curl -I http://127.0.0.1/ systemctl status firewalldss -tlnp看端口是否真的在监听如果在监听但访问失败问题在防火墙或 SELinux。firewall-cmd --list-all能看放行规则添加端口用firewall-cmd --permanent --add-servicehttp firewall-cmd --reload第八课阶段不要求你把防火墙玩得很深但至少要建立这个排查顺序先确认进程活再确认端口通再确认防火墙放行最后再考虑 SELinux。90% 的服务无法访问问题都被这四步覆盖其中至少有一半出在防火墙和 SELinux进程本身根本没问题。5. 备考与实操我建议的第八课练习方法和踩坑记录5.1 一个 15 分钟就能完成的验证流程书本知识学完不动手等于没学。我给自己定的练习流程很简单每次大约 15 分钟专治“看得懂、敲不出来”的毛病。选一个服务比如 sshd停掉它systemctl stop sshd用systemctl is-active sshd确认状态尝试连接一台远程机器发现连不上验证停止效果真实生效启动它再确认能重新连上执行systemctl disable sshd然后重启系统确认开机后没有自启执行systemctl enable sshd再重启确认服务回来了整个过程结束后用systemctl status sshd和journalctl -u sshd -n 20留下记录。整个过程不需要复杂环境一台虚拟机就够。关键是最后要能用自己的话解释出“为什么步骤 5 之后重启服务没起来”如果解释不出来说明还没有真正理解 unit 文件和 target 的关系。5.2 考试里最容易丢分的三个点第一个是restart 和 reload 的选择。考题经常说“修改了配置文件请让配置生效且不影响业务”如果你写 restart即使服务起来了严格意义上也不符合题意因为连接被中断了。优先 reload 的语义才是题目要的。第二个是enable 后没有 start。有人执行了systemctl enable httpd然后立刻问为什么现在访问不了因为 enable 只管开机自启不管当前状态。想一条命令同时搞定用enable --now但你要理解它等价于 enable 再 start。第三个是mask 滥用。做安全加固相关题目时需求往往只是“开机不要启动”很多人为了保险直接 mask结果后续步骤里服务怎么都启动不了反过来怀疑系统坏了。mask 是锁死不是简单禁止自启用之前想清楚。5.3 超出考试范围的几个实用意识学完第八课之后我建议你把研究的边界稍微再往外推一层但不要陷进去。比如systemd-analyze blame可以看开机时每个服务的耗时systemd-analyze critical-chain可以看哪条启动链路最慢。这些命令对优化启动速度很有帮助也是把第八课知识延伸出去很自然的方向。另外在真实服务器上做任何操作之前养成交替确认的习惯启动服务前看一遍配置文件语法重载服务前确认配置文件路径重启系统前确认默认 target 正确。RH124 第八课教给你的是一套“服务控制”的门路但真正值钱的是这套门路变成肌肉记忆之后你在故障现场不用翻文档也能冷静排查的状态。写到这里我自己的体会是学 systemd 这一课最忌讳的就是只背命令不拆 unit 文件只要把 unit 文件看明白后面所有 systemctl 操作都是在和一段明文配置打交道。建议你今天就拿一台虚拟机把 sshd 或者 httpd 的 unit 文件打开逐个字段读一遍再按上面的流程完整跑一轮比盯着课程 PPT 看两个小时有用得多。
