systemd与systemctl核心操作：RH124第9章服务控制实战详解

1. 为什么这一章值得反复啃学 RH124 的人很多都是冲着 RHCSA 考试去的。但说句实话前面几章讲目录结构、文件权限、文本处理都是“静态知识”背一背、练一练就有把握。到了第 9 章“控制服务和守护进程”画风突然变了——这一章教的是怎么让系统按你的意愿跑起来、跑下去、跑不动了怎么救。这已经不是“记命令”的层面而是从“会用 Linux”跨到“会管 Linux”。只要是跑 Linux 的机器无论是物理机、虚拟机还是云主机都离不开服务的启停管理。你装上 Nginx要让它开机自启你改完 MySQL 配置要重载而不是重启你写好一个定时备份脚本想把它封装成一个服务单元。这些事情在第 9 章会有一个清晰的答案。再往后如果你遇到服务突然挂了、开机进不了图形界面、某进程莫名其妙被杀这类问题排查思路也基本是从这里延伸出去的。所以我不太愿意把这一章定位成“考点”它更像是整个 RHCSA 实操部分的基石。2. systemd 的底层逻辑为什么服务管理绕不开它2.1 先搞清楚一个根本问题systemd 到底管什么在 RHEL 7 之前主流 Linux 发行版用的是 System V init简称 SysVinit。那套机制说穿了就是一堆 shell 脚本。系统启动时内核启动 1 号进程init然后 init 根据运行级runlevel挨个执行 /etc/rc.d/rc*.d 目录下的脚本。脚本之间靠命名编号决定先后顺序比如 S01kvm、S02network、S03sshd。这种方式有两大硬伤一是串行执行启动过程慢二是脚本之间没有依赖关系只有“先后”约定经常出现服务启动了但依赖的东西还没就绪的情况。systemd 的设计思路完全不同。它把“服务”抽象成单元unit每个单元用一个纯文本文件描述里面声明了启动命令、依赖关系、重启策略。systemd 在开机时并行处理没有依赖冲突的单元大大缩短启动时间。更重要的是它提供了 systemctl 这样一个统一入口让你管服务、管开机自启、看日志、切系统状态全都在一个工具下完成。打个比方。SysVinit 时代的管理员像是按流程表逐项打钩的质检员而 systemd 更像一个项目经理它自己会画依赖图判断哪些活可以先干、哪些必须等别人干完。你要做的不是告诉它“第几步做什么”而是告诉它“我要什么结果”。2.2 单元文件systemd 管理一切的最小单位systemd 里的“单元”可以是服务.service、挂载点.mount、设备.device、套接字.socket、定时器.timer、目标.target等类型。日常工作中接触最多的是 .service 和 .target。单元文件存放在三个位置优先级从低到高/usr/lib/systemd/system/软件包安装时自带的单元文件不要直接改。/run/systemd/system/运行时生成的单元文件重启后消失。/etc/systemd/system/管理员自定义或覆盖的单元文件优先级最高。这三个位置的设计意图很明确系统自带的文件归软件包管包管理器升级时会覆盖你需要改配置时把覆盖文件放到 /etc/systemd/system/ 下既不影响包管理又能让 systemd 优先采用你的版本。打开一个典型的服务单元文件比如 Nginx 的通常有三个段落[Unit]描述单元本身。Description 是说明文字After、Before 定义启动顺序Wants、Requires 定义依赖。[Service]定义启动行为。ExecStart 是启动命令ExecStop 是停止命令Type 指定进程启动方式Restart 定义退出后的动作。[Install]定义“安装”行为主要是 WantedBy 或 RequiredBy决定服务在哪个 target 下被启用。一个最小可用的单元文件长这样[Unit] DescriptionMy custom daemon [Service] ExecStart/usr/local/bin/mydaemon Restarton-failure [Install] WantedBymulti-user.target这里有个新手常犯的错只写了 ExecStart没写 Type。Type 默认是 simple意思是 ExecStart 启动的进程本身就是服务主进程。但如果你启动的是一个脚本脚本里用 nohup 启动了一个子进程然后自己退出了那 systemd 会认为服务已经结束导致状态判断错误。这种情况应该把 Type 改成 forking。2.3 为什么 target 比运行级更好用SysVinit 时代你用 init 3、init 5 切换文本/图形模式。systemd 用 target 代替了运行级运行级和 target 的对应关系大致是运行级target 单元含义0runlevel0.target → poweroff.target关机1runlevel1.target → rescue.target单用户恢复模式2 / 3 / 4runlevel2.target、runlevel3.target、runlevel4.target → multi-user.target多用户非图形界面5runlevel5.target → graphical.target多用户图形界面6runlevel6.target → reboot.target重启target 和运行级最大的区别是target 可以组合运行级只能互斥。graphical.target 本身会依赖 multi-user.target而 multi-user.target 又依赖 basic.target、sysinit.target。这种依赖树让系统可以并行启用所有需要的单元而不是一个个顺着跑。3. systemctl 实操形成你的“肌肉记忆”3.1 服务生命周期命令不能只停留在背命令start、stop、restart、reload 这四个命令几乎每个教程都会列但它们之间的差别值得多想一步start启动当前未运行的服务。如果服务已经在运行再次 start 会报错还是没反应答案是不会有额外效果也不会报错但有些版本会提示“Job is already active”。stop终止服务。注意 systemd 会先发 SIGTERM等一段时间后还没退出才发 SIGKILL。这个“等”默认是 90 秒由 TimeoutStopSec 控制。restart等于 stop 再 start。如果服务配置有问题导致起不来restart 会立刻暴露问题。reload只重载配置文件不中断进程。改成 reload 的正确时机是服务的配置是“每次请求时读取”的比如 Nginx、sshd、httpd。如果你改了配置后直接 restart请求中的连接会断掉用 reload 就能无缝切换。我在实际运维中养成了一个习惯能用 reload 的场景绝不用 restart。有一次在大白天改某 Web 服务的并发参数直接 restart 导致几十个活跃连接断开业务方立刻来问。后来学乖了先用 nginx -t 验证配置语法再 systemctl reload nginx。配置有问题时 reload 会失败此时服务依然在旧配置下运行不会造成事故。3.2 enable 和 disable 不是“开机启动开关”那么简单很多初学者把 enable 理解为“设置开机自启”这不算错但没有触及本质。enable 的作用是创建符号链接把单元文件链接到某个 target 的 .wants 目录下。比如你执行systemctl enable sshd系统会在 /etc/systemd/system/multi-user.target.wants/ 下创建指向 sshd.service 的符号链接。systemd 启动 multi-user.target 时会自动扫描这个目录把所有链接的服务都启动起来。disable 就是删除这个链接此后服务不会随系统启动但你仍然可以手动 start。关键区别来了。enable 只是“开机时自动启动”不是“现在立即启动”。如果你想让服务现在就跑且以后也开机自启两个动作都要做。很多新手在刚装上 MySQL 后执行 systemctl enable mysqld以为服务已经起来了一访问发现连接被拒绝就是这么回事。另外修改 /usr/lib/systemd/system/ 下的单元文件后或者自己创建了一个新的单元文件都需要执行systemctl daemon-reload它的作用是让 systemd 重新加载单元文件把内存里的配置刷新一遍。如果你不执行systemd 可能还在用旧版本配置甚至认不出你新建的单元。这个命令不会重启任何服务只是刷配置所以很安全可以随时执行。3.3 用两个查询命令快速摸清系统状态日常用得最多的两个查询是systemctl list-units --typeservice --staterunning systemctl list-unit-files --stateenabled第一条列出当前正在运行的所有服务单元适合快速确认本机在跑什么。第二条列出所有“开机自启”的服务单元适合在排查启动慢、异常进程时用。两者的区别list-units 看的是运行时状态list-unit-files 看的是配置文件里的启用状态。一个服务可能已经启用enabled但因为手动 stop 而没在运行一个服务可能没有启用但被别的服务临时拉起此刻正在运行。还有一个容易忽略的查询systemctl status sshd它不只是告诉你“active (running)”这么简单。它还会显示主进程 PID、内存占用、最近的日志记录、以及该服务监听的端口相关信息。排查一次启动失败status 往往是最先要看的输出。4. 依赖、目标与自定义服务把控制权握在手里4.1 After、Wants、Requires 到底怎么选这是第 9 章里理解成本最高的概念也是实际写单元文件时最容易出错的地方。After / Before 只定义顺序不定义因果关系。A 写了 AfterB意思是 B 必须先启动。但 A 不会主动把 B 拉起来如果 B 没被启动A 依然会启动。Wants 是“弱依赖”。A 写 WantsBsystemd 会尽量把 B 也启动。但如果 B 启动失败A 照样启动互不影响。Requires 是“强依赖”。A 写 RequiresBB 启动失败时A 也不会启动。实际场景中Wants 比 Requires 用得多。比如你有一个业务服务依赖网络通了才能正常工作但你不想因为网络服务network.service出问题就导致业务服务完全不可用用 Wants 更合适Requires 会让链路更严格常用于“没有数据库应用服务毫无意义”的场景。顺序用 After 或 Before依赖用 Wants 或 Requires两者组合起来表达完整策略。比如[Unit] DescriptionMy application Afternetwork.target Wantsnetwork.target这句话的意思是等网络目标就绪后再启动本服务顺便把网络目标启用。如果删掉 After虽然 Wants 会触发网络启动但两者是并行执行的不保证网络已就绪时服务才启动。4.2 把运行级思维切换成 target 思维用 systemctl 时很多人习惯了老一套的运行级概念会遇到两个具体问题。第一个是切换默认运行级别。旧命令是ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target现在不用手动建链接了直接systemctl set-default multi-user.target systemctl get-default第二个是临时切换当前状态。比如图形界面卡住了想临时切到纯文本模式可以用systemctl isolate multi-user.targetisolate 的意思是停掉当前 target 下不需要的单元启动目标 target 依赖的单元。但注意isolate 是有“杀伤力”的它会把当前 target 多余的单元全部停止。有人曾在生产机上执行 systemctl isolate rescue.target结果图形界面和网络服务全部停了只能去机房处理。你如果只是想暂时离开图形界面至少要先确认网络服务在 rescue.target 里也会启动否则后果自负。4.3 完整案例把一个脚本封装成 systemd 服务这个场景几乎每个人都会碰到写了一个 Python 脚本或者 Shell 脚本希望它开机自启、崩溃后自动拉起。用 crontab 的 reboot 能解决一部分问题但没监控、没重启策略、没日志集成。改成 systemd 服务是正道。假设我有一个简单的监控脚本 /usr/local/bin/disk_check.sh每 30 秒检查磁盘空间并记录到日志。单元文件写好后长这样[Unit] DescriptionDisk usage check script [Service] Typesimple ExecStart/usr/local/bin/disk_check.sh Restarton-failure RestartSec30s [Install] WantedBymulti-user.target关键参数说明Typesimple脚本本身常驻前台不会自己 fork 出子进程再退出。Restarton-failure只在异常退出时重启正常退出exit 0不会重启这个策略最适合守护类脚本。RestartSec30s重启前等待 30 秒防止脚本崩溃后狂重启烧 CPU。写完单元文件后按顺序执行四个命令systemctl daemon-reload systemctl enable disk_check.service systemctl start disk_check.service systemctl status disk_check.service我这里要特别提一下顺序先 daemon-reload再 enable最后 start。如果你先 start再写 enable可能会遇到“Unit disk_check.service not found”之类的问题因为 systemd 还没加载新单元。严格按这个顺序操作是最省心的做法。5. 日志与故障排查服务起不来的完整解法5.1 journalctl 是你必须养成的第一直觉传统日志分散在 /var/log/messages、/var/log/secure、/var/log/nginx/ 等文件里。systemd 把所有被自己托管进程的输出统一收集到 journal 里用 journalctl 查询。常用参数我列个速查表参数作用journalctl -u sshd查看 sshd 服务相关的所有日志journalctl -u sshd -f实时跟踪该服务的日志journalctl -b查看本次开机以来的日志journalctl -b -1查看上一次开机期间的日志journalctl -p err只看级别为 error 及以上的日志journalctl --since today只看今天的日志journalctl --until 2024-01-01 00:00只看某个时间点之前排查服务问题我的固定套路是三步systemctl status myservice journalctl -u myservice --no-pager -n 50 systemctl cat myservice第一步确认服务状态和最近事件第二步看最近的 50 行日志第三步确认 systemd 实际加载的配置内容。三步走完绝大多数问题的原因已经浮出水面。journal 日志的一个坑是默认不持久化。重启后之前的日志就没了除非你改了配置。改法是在 /etc/systemd/journald.conf 里设置Storagepersistent然后重启 systemd-journald。这样日志会写入 /var/log/journal/ 下。做运维的最好一开始就把这个开关打开否则排查“上一次启动时发生了什么”会很痛苦。5.2 常见失败原因速查表我在帮人排查服务起不来的时候发现原因翻来覆去就那几类。整理成一张速查表新手排查时直接对照现象常见原因排查方式ExecStart 报 no such file命令路径写错或不存在在 shell 里手动执行该命令验证ExecStart 报 Permission denied脚本没有执行权限chmod x 脚本文件服务状态显示 active (exited)脚本里命令执行完就退出Type 不匹配改成 Typeforking 或用循环保持前台运行服务启动失败但日志无输出SELinux 阻止了进程ausearch -m avc -ts recent 看拒绝记录服务反复 Restart启动脚本本身有问题或依赖服务没起来journalctl -u 服务名 查看具体报错enable 时找不到单元文件没执行 daemon-reload先执行 daemon-reload 再操作改了配置不生效忘了 reload 或 restartsystemctl reload/restartSELinux 这一条很容易被忽略。有一次我写了一个脚本服务ExecStart 指向 /opt/script/run.sh脚本权限正常、路径正常手动执行也没问题但 systemctl start 就是失败。后来用 ausearch 查了 AVC 日志发现是 /opt 目录下的自定义脚本被 SELinux 策略拒绝了。解决办法是用 semanage fcontext 给该目录设置正确的上下文类型再 restorecon -Rv。这类问题的核心思路是排除了权限和路径问题后一定要想到 SELinux。5.3 实操中踩过的几个真坑第一个坑ExecStart 里写了相对路径。systemd 执行命令时工作目录不是你想象的那样它默认继承 systemd 的环境而不是某个用户的家目录。所以 ExecStart 必须写绝对路径脚本中引用的文件、配置文件也要用绝对路径否则服务启动成功但行为异常因为找不到文件走了分支逻辑。第二个坑PIDFile 路径写错。某些 forking 类型的服务比如数据库会在启动时生成 PID 文件。如果你在单元文件里写了 PIDFile但服务实际把 PID 写到别的路径systemd 会因为“找不到 PID 文件”判定服务启动失败。解决方法是根据服务的实际行为修改 PIDFile 路径或者干脆不写这一项让 systemd 自己识别。第三个坑环境变量缺失。脚本在交互式 shell 里能跑因为用户环境变量齐全但 systemd 启动进程时只保留极少的环境变量PATH 往往被精简到最小集合。我见过一个备份脚本在命令行执行正常做成服务后每次都失败最后发现是脚本里用了 python3而 systemd 环境下的 PATH 没有包含 /usr/local/bin导致找不到解释器。处理方式是 ExecStart 里写解释器的完整路径或者在 [Service] 段用 Environment 补全环境变量。6. 进阶操作与备考建议6.1 mask 和 disable 的区别这两个命令的坑最深disable 只是移除开机自启的符号链接服务仍然可以被手动 start。如果你希望某个服务彻底“禁用”连手动启动都不行用 masksystemctl mask firewalldmask 的实现原理是把单元文件链接到 /dev/nullsystemd 看到这个服务时直接认为它是“无法启动”的。执行后你再 start 会明确报错“Unit is masked”。这在安全加固、防止某服务被误启动时非常有用。反过来操作是 unmask。我个人经验是能用 disable 解决的需求先别急着 mask。因为 mask 之后有些软件安装包升级时会尝试重启服务一旦发现服务被 mask安装脚本可能报错。disable 的风险小得多。6.2 救援模式与临时系统状态切换如果系统出现故障比如图形界面崩溃、无法正常进入多用户模式systemctl 也有对应的处理方式。rescue.target等价于旧的单用户模式。进入后只有基本文件系统和少量服务适合修复系统故障。emergency.target更极简只挂载根文件系统适合处理磁盘损坏等严重问题。服务器上遇到问题可以用 systemctl isolate rescue.target 临时进入救援模式。处理完再用 systemctl default 回到默认 target。这里要提醒的是在远程服务器上执行 isolate rescue.target 之前先确认该机器有带外管理渠道比如远程控制卡或机房管理口。否则网络服务可能会停掉你等于亲手把自己关在门外。6.3 学习路径与实验建议RH124 的设计本身是循序渐进的第 9 章的内容适合配合虚拟机反复练习。我的建议是搭两到三台虚拟机一台纯文本启动一台图形界面一台做各种破坏性实验。破坏性实验一定要做。比如把 sshd.service 的 ExecStart 路径故意写错观察 systemd 的报错把 firewalld mask 掉再启把默认 target 改成 multi-user.target 再改回来把一个 Typesimple 的服务故意改错成 forking。这些操作在真实机器上不敢做在虚拟机上随便折腾。每试坏一次先自己试着修复实在修不好再重置快照。这套练下来你对 systemd 的理解会比只刷题深刻得多。考试方面RHCSA 对 systemd 的考察重点集中在 systemctl 基础操作、开机自启配置和 target 切换。用 systemctl list-unit-files 查看状态用 systemctl status 定位问题这部分是必考。建议把命令练到不用思考就能敲出来的程度因为考试时间有限多留一分钟给后面的排错题就是多一分把握。最后给一个实验作业创建一个服务要求它开机自启如果崩溃后每隔 5 秒自动重启并且限制它最多重启 3 次。这个作业需要用到 Restart、RestartSec 和 StartLimitBurst 三个参数。做完这个练习你对单元文件的掌握基本就过关了。