1. 从命令行到系统启动这一章到底在解决什么问题RH124 的复习进度走到第八篇前面七篇已经把命令行、文件管理、用户权限这些基本功捋得差不多了剩下的内容看标题就知道开始从“操作文件”转向“管控系统本体”了。这个章节的核心关键词就两个systemd 和日志排查。说白了就是解决一个非常现实的问题——你在一台 Linux 服务器上执行了 reboot 之后系统到底按照什么顺序把乱七八糟的服务拉起来某个服务挂了你用什么手段在第一时间找到原因很多人学 Linux 学到这个地方会突然觉得吃力原因在于前面几章的知识都是“静态”的——文件就在那里权限就在那里你只要学会查看和处理就行。但从 systemd 开始所有的概念都是“动态”的服务在跑、进程在跳、日志在滚你面对的不再是一个文件而是一整套运行机制。这种思维切换是需要一点时间的别急这一篇我把题目里提到的 systemd 管理、服务配置、journalctl 日志体系、启动目标和开机自启这些点全部拆开讲清楚。这篇内容适合谁看一个是准备考红帽认证或者正在刷 RH124 的学员另一个是刚接触 Linux 运维、但之前只知道敲几个 cd/ls 命令的新人。我把每一个命令背后的设计思路也讲明白不是说光让你记参数而是让你真的理解 systemd 为什么这么设计这样遇到文档里查不到的场景你也能自己推理出答案。2. 先建立整体认知systemd 到底是个什么玩意儿2.1 从 SysVinit 到 systemd 的一次架构升级要理解 systemd先得知道它替代的是什么。老一代的 Linux 发行版用的是 SysVinit它的工作模式特别像你上学时候的值日表系统启动时执行一个总脚本然后按照数字顺序去执行 /etc/rc.d/ 下面的一系列脚本比如 S01syslog、S05network、S10sshd 这样数字小的先执行数字大的后执行。这种方式简单直观但问题也很明显每个服务脚本自己要处理启动、停止、状态查询这些逻辑脚本之间互相不知道对方是否就绪启动速度慢而且并行能力极差。systemd 把这一切推倒重来它采用的是一种“按需启动 并行启动”的机制。每个服务被定义成一个 unit单元unit 之间用依赖关系组织起来。systemd 作为第一个启动的进程PID 1负责把所有单位按照依赖关系图并行地拉起来哪个不依赖另一个就可以同时启动。这个架构带来的直接好处是开机速度肉眼可见地变快服务管理方式统一你在 systemd 体系下根本不需要再去写那些一大堆 case 分支的 init 脚本。提示现在 RHEL/CentOS/Rocky 全系都是用 systemd 作为 init 系统的Ubuntu 16.04 之后的版本也切过来了。所以你学的这套东西在 95% 以上的现代 Linux 服务器上都是通用的。2.2 unit 文件的类型和存放位置理解 systemd 的下一步是理解它的 unit 类型。一个 unit 代表一个系统资源的定义它可以是服务、可以是挂载点、可以是设备、可以是定时任务。RH124 阶段你只需要掌握最核心的几类但底层的机制是一样的。常见的 unit 类型包括 service、target、socket、timer、mount、path 等。其中 service 是最常用的对应一个后台守护进程target 是一组 unit 的集合你可以把它理解为“启动层级”或者“运行级别”的新版说法。unit 文件放在哪里也是有讲究的记住一个优先级/etc/systemd/system/ 下的文件优先级最高其次是 /run/systemd/system/最后才是 /usr/lib/systemd/system/。换句话说官方软件包安装时自带的 unit 文件放在 /usr/lib/systemd/system/而你手动创建的、或者通过 systemctl enable 生成的那些链接文件放在 /etc/systemd/system/。如果你要覆盖某个服务自带的配置最好的做法不是直接改 /usr/lib 里的原文件而是把自定义配置放到 /etc 下这样系统升级时你的改动不会被覆盖。2.3 systemctl 命令家族管理 unit 的日常操作管理 unit 状态的主要工具是 systemctl这一套命令必须练到肌肉记忆的程度。查状态、启动、停止、重启、开机自启这些基础操作我就不多说了关键是几个容易忽略但实际工作中高频使用的命令。systemctl status 是你排查故障的第一步它不但告诉你服务当前是 active 还是 failed还会顺手把最近几条日志贴出来很多问题一眼就能看出原因。systemctl list-units --typeservice --staterunning 可以列出当前所有正在运行的服务这个命令在你要快速确认机器上到底跑了哪些东西时特别好用。systemctl list-unit-files 则用来查看所有 unit 的启用状态注意它和 list-units 的区别一个管“磁盘上的定义是否存在”一个管“内存里当前是否在运行”。命令本身不难背难的是理解每个命令背后的意图。你写 systemctl enable xxx 的时候本质是在 /etc/systemd/system/ 下的 multi-user.target.wants 目录里创建一个符号链接指向 /usr/lib/systemd/system/ 下的真实 unit 文件。理解了这一点你就明白为什么 enable 之后还要 start——enable 只是设定了“开机时启动”的意图start 才是立即拉起服务这两件事经常被新手混为一谈。3. 拆解 unit 文件自己写一个能被 systemd 管理的服务3.1 unit 文件的三段式结构看到这里光会用 systemctl 还不够你要能自己编写 unit 文件才能算真正理解 systemd 的设计哲学。一个典型的 service unit 文件由三个段落组成[Unit] 段定义描述信息和依赖关系[Service] 段定义服务本身怎么启动[Install] 段定义服务如何被 enable。给你一个最小可用的例子[Unit] DescriptionMy test service Afternetwork.target [Service] Typesimple ExecStart/usr/local/bin/mytest.sh Restarton-failure [Install] WantedBymulti-user.target这个文件只有十二行左右但每个字段都有讲究。Description 就是给人看的说明文字systemctl status 里显示的那行就是它。After 表示这个服务要在 network.target 之后启动注意它只是“顺序上的依赖”不是“必须的依赖”——关于 Wants、Requires、After 三者的区别我下面专门讲。[Service] 段是最核心的。Typesimple 告诉 systemdExecStart 启动的进程就是主进程这是最常见的类型适用于那些启动后不 fork、不 daemonize 的程序。如果你的程序启动后会自动 fork 成后台进程那要用 Typeforking同时通常还需要配一个 PIDFile 让 systemd 能找到主进程的 PID。Restarton-failure 是生产环境里必配的字段它让服务在异常退出时自动拉起保证可用性。[Install] 段里的 WantedBy 是最常见的安装方式。WantedBymulti-user.target 表示当用户执行 systemctl enable 时会在 /etc/systemd/system/multi-user.target.wants/ 目录下创建符号链接。只要那个 target 被启动这个服务就会跟着启动。3.2 Wants、Requires 和 After三种依赖关系的本质区别这三个字段是所有 systemd 初学者都会绕晕的地方我用大白话梳理一遍。After 只管“顺序”不管“生死”——A 配置了 AfterB意思是如果 B 存在那么 A 在 B 启动完成之后才启动但 B 挂了或者根本不存在A 照样能启动。Wants 是“弱依赖”——A 声明了 WantsB那 systemd 启动 A 的时候会尝试顺手启动 B但如果 B 启动失败了不影响 A 继续启动。Requires 是“硬依赖”——A 声明了 RequiresBB 必须启动成功A 才开始启动B 挂了之后 A 也会被停掉。用一个生活化的例子你早上出门上班After 相当于“我老婆必须先出门我才出门”但老婆今天请假不出门你照样能走Wants 相当于“我希望能吃个早饭再走但来不及就算了”Requires 相当于“我身份证必须带着没带身份证我就走不了”。实际配置里最常见的组合是 After Wants 搭配或者 After Requires 搭配。After 保证顺序Wants/Requires 决定是否需要拉起另一个 unit。RH124 考试不考这种非常深入的依赖设计但你自己写服务时、排查“为什么这个服务起来导致另一个服务挂了”时这个理解是排障的钥匙。3.3 动手实操从脚本到服务一个完整的例子为了让你对 unit 文件的理解不是停留在纸面上我带你把一个普通脚本变成一个可被 systemd 管理的服务整个过程五分钟内可以跑通。第一步写一个简单的测试脚本。假设这个脚本的作用是循环记录当前时间到日志文件#!/bin/bash while true; do echo $(date %Y-%m-%d %H:%M:%S) tick /var/log/mytest.log sleep 5 done第二步把脚本保存到 /usr/local/bin/mytest.sh并加执行权限。记住 ExecStart 里写的内容要么是一个二进制可执行文件的绝对路径要么是一个脚本的绝对路径。如果是脚本脚本本身必须有 x 权限而且文件开头要有 shebang#!/bin/bash。第三步编写 unit 文件放到 /etc/systemd/system/mytest.service内容就是上面那个最小示例ExecStart 改成 /usr/local/bin/mytest.sh。第四步重载 systemd 配置。这一步绝对不能省因为 systemd 是常驻内存的你新增或修改了 unit 文件它不会自动感知必须手动执行 systemctl daemon-reload 让它在磁盘上重新扫描 unit 定义。第五步启动并验证。systemctl start mytest systemctl status mytest journalctl -u mytest -f如果你在 journalctl 里能看到每隔五秒打印一条带时间戳的记录说明整个链路通了。这个实验虽然简单但你亲手把一个普通脚本变成了一个可以开机自启、崩溃自动重启、日志可以被统一管理的关键部件这个体验比背十遍参数值钱得多。4. target 与开机自启系统是怎么把服务按顺序拉起来的4.1 什么是 target为什么要用 target在老的 SysVinit 体系里有三个运行级别3 是命令行模式5 是图形界面模式。systemd 用 target 替代了运行级别而且更灵活。target 本身也是一种 unit只不过它的作用是把一堆其他 unit 打包成一个整体。比如 multi-user.target 就等价于老体系的“级别 3”它代表一个多用户可登录的命令行环境graphical.target 等价于“级别 5”在 multi-user.target 的基础上额外启动图形界面相关服务。target 内部是通过 Wants 或者 Requires 来引用其他 unit 的。你执行 systemctl enable 一个服务时系统会在对应的 target 的 .wants/ 目录下创建符号链接这就是“开机自启”的物理本质。理解了这个机制你就明白为什么 enable 一个服务实际上并没有修改 /usr/lib/systemd/system/ 里的原文件而是在 /etc/systemd/system/ 里建了一个链接。4.2 查看和修改默认启动目标查看当前系统默认的启动目标用这个命令systemctl get-default在服务器上通常返回的是 multi-user.target因为我们不需要图形界面。如果你想改默认目标比如一台装了桌面环境的机器想默认进入命令行systemctl set-default multi-user.target这个操作会修改 /etc/systemd/system/default.target 这个符号链接让它指向 multi-user.target。注意这里不需要 daemon-reload因为链接是在文件系统层面改的。临时切换启动目标也有一个命令systemctl isolate。它的含义是把当前运行的 unit 集合切换到指定的 target。你可以理解成“立即切换到某个运行级别”但这个命令有风险因为如果你切换到一个不包含 sshd 服务的 target服务器会瞬间失联。建议只在有本地控制台机房里的显示器键盘或者云平台的控制台 VNC的情况下做这类操作。4.3 一个容易忽略但超实用的配置内核启动参数指定 target还有一个很小众但值得知道的知识点在 GRUB 引导界面你可以临时指定系统启动到哪个 target。操作方法是在内核启动参数那一行尾部加上 systemd.unitrescue.target然后按 CtrlX 启动。这样就能进入免密码实际上还是需要 root 密码的救援模式适合在系统起不来、但你又需要挂载文件系统修复问题的时候使用。RH124 不会考这个细节但你在实际运维中遇到“系统启动一半就卡住”的场景时这个知识点能救命。5. journald 日志体系用日志反推故障现场5.1 journald 和 rsyslog 的恩怨情仇讲完服务的启动和管理接下来要解决另一个核心问题服务出问题了怎么排查Linux 系统的日志体系经历过一次大变革。传统的方式是 rsyslog它把不同的日志写入不同的文本文件比如 /var/log/messages、/var/log/secure、/var/log/cron这种方式文本可读性好老运维都很习惯。但 systemd 带来了自己的日志服务 journald它使用二进制格式存储日志并把所有来源的日志包括内核、服务、标准输出统一收集。你可以在 /run/log/journal/ 或者 /var/log/journal/持久化之后找到这些二进制日志文件。二进制格式带来一个好处查询能力极强可以按时间、按 unit、按优先级、按可执行文件路径等维度做精细过滤这是纯文本文件很难做到的。实际服务器上两者通常是共存的。journald 负责收集和索引rsyslog 仍然可以从 journald 读取日志并写入文本文件提供给传统工具查看。你不需要在自己的服务器上关掉任何一个理解它们的关系即可。你只需要知道排查问题时先用 journalctl 快速过滤定位到具体方向后再决定要不要去 /var/log/messages 里翻更长时间跨度的记录。5.2 journalctl 的十种常用姿势逐一讲解journalctl 是查看 systemd 日志的唯一入口我按使用频率整理了一份命令清单每一条都配上适用场景。第一条查看某个服务的所有日志journalctl -u sshd这是最基础但也最刚需的命令。-u 指定 unit 名称后面可以跟服务名也可以跟 .service 后缀。第二条实时跟踪某个服务的日志journalctl -u sshd -f-f 的含义是 follow和 tail -f 一个道理日志有新内容时自动滚动输出。这个命令在调试服务启动失败时几乎必用因为服务启动时的错误信息通常只会刷一次用 -f 可以确保你看到的是最新状态。第三条查看系统启动以来本次运行的日志journalctl -b默认不加参数时journalctl 显示的就是当前这次启动的所有日志。如果你之前发生过故障系统重启之后想把上一次启动时的日志拉出来看可以用 journalctl -b -1 指定上一次启动-2 就是上上次以此类推。这个能力非常强大——系统崩了重启后你想复盘崩之前发生了什么这是唯一途径。第四条按时间范围过滤journalctl --since 2024-01-01 08:00:00 --until 2024-01-01 10:30:00这两个参数支持非常灵活的写法--since 10 minutes ago 这种相对时间也是允许的。排障时先确定故障发生的大致时间窗口然后用这两个参数把日志范围缩到最小能省掉你大量翻日志的时间。第五条查看内核日志journalctl -k内核日志平时是混在 systemd 日志流里的-k 帮你把内核相关的独立筛出来。硬件识别失败、驱动加载报错这类问题就看它。第六条按优先级过滤journalctl -p err-p 后面跟优先级emerg、alert、crit、err、warning、notice、info、debug从高到低。指定 err 表示只显示 error 及以上级别的日志。这个命令适合在大流量背景下快速找到高优先级错误。第七条查看上次启动的日志并带上错误级别这是故障复盘最常用的组合拳journalctl -b -1 -p err一次启动的完整日志可能有几万行加上 -p err 过滤后可能只剩十几个条目都是重点检查对象。第八条查看某个可执行文件产生的所有日志journalctl /usr/sbin/sshd这个写法和 -u sshd 看着类似但本质不同。直接写路径时journald 会筛选所有由这个可执行文件产生的日志不管它是作为哪个 unit 的子进程跑的。第九条查看某个进程 PID 的日志journalctl _PID1234这种下划线开头的字段叫 journald 的“匹配字段”除了 _PID还有 _COMM命令名、_UID用户 ID、_HOSTNAME主机名等。这个玩法可以和其他过滤条件组合使用实现非常精准的日志定位。第十条查看指定 unit 的完整状态输出包括最近日志systemctl status sshd严格来说这不是 journalctl 的命令但它在排障时的地位非常高。status 命令会显示服务的主进程 PID、内存占用、最近状态变化并且自动带出最近的几行日志。很多时候你还没意识到要用 journalctlstatus 里贴出的那几行日志就已经把问题说清楚了。5.3 日志持久化重启后还能不能查到历史日志journald 默认情况下把日志存在内存文件系统里服务器一重启之前的日志就丢了。要让日志持久化保存你需要手动创建一个目录并调整配置。做法很简单mkdir -p /var/log/journal systemctl restart systemd-journald当 systemd-journald 检测到 /var/log/journal 目录存在时会自动把日志持久化到这个目录下。这个操作做完之后之前的日志也不会完全恢复——但之后新产生的日志就都能在重启后保留下来了。生产环境强烈建议做这一步否则你连“上次启动为什么挂了”都查不了。提示日志持久化后/var/log/journal 目录的大小会持续增长。建议关注一下系统里是否配置了 journald 的日志轮转策略核心配置在 /etc/systemd/journald.conf 的 SystemMaxUse 字段。不在 RH124 考试范围但生产环境早晚会遇到磁盘被日志塞满的事故。6. 实操场景手动搭建一个服务并实现开机自启6.1 一个需求明确的服务注册全过程前面讲了这么多理论和命令现在把整个流程串起来跟着做一遍就能形成肌肉记忆。假设我现在需要在一台 RHEL 系的服务器上部署一个简单的 Nginx 服务并且要求它开机自启、崩溃自动拉起。实际上 Nginx 的安装包本身自带了 unit 文件不需要手动写但把它当作理解载体非常合适。第一步安装并确认软件的 unit 文件存在dnf install -y nginx systemctl status nginx如果包管理器的 spec 文件写得好装完软件后 systemctl status nginx 就能直接看到 unit 信息。有些软件装完并不会自动启动必须手动 start。第二步直接启动并设置开机自启systemctl start nginx systemctl enable nginx这里我还是要强调start 和 enable 含义不同所以在生产环境你经常能看到一条组合命令systemctl enable --now nginx它等价于 enable 和 start 两条命令一起执行。有 --now 就用它没有就分开敲。第三步验证状态systemctl is-active nginx systemctl is-enabled nginxis-active 看当前是否运行中is-enabled 看是否开机自启。这两个命令在写自动化脚本时特别实用因为它们是纯文本输出active/disabled 这样的结果能直接被 shell 脚本判断。第四步反向验证开机自启是否生效——检查符号链接ls -l /etc/systemd/system/multi-user.target.wants/nginx.service你应该能看到一个指向 /usr/lib/systemd/system/nginx.service 的符号链接。看到这个链接就说明 enable 这个动作在文件系统层面的体现就是创建了软链。整个过程不算复杂但如果你能亲手敲一遍并且注意到 start 和 enable 之间的区别、注意观察符号链接的创建你对 systemd 的理解会提升一个台阶。6.2 服务起不来了最直接的排查路径服务启动失败是运维的日常我给你一套经过验证的排查路径遇到问题照着走就行。第一步查看服务状态。这一步能排除 80% 的问题systemctl status xxx重点关注状态行里的 active (running)、failed、inactive (dead) 三种状态。以及这行下面的日志摘录。如果状态显示 failed说明服务确实启动失败而且 status 里通常会直接给出失败原因比如端口被占用、配置文件语法错误。第二步看详细日志。如果 status 给的信息不够用 journalctl 拉最近日志journalctl -u xxx -b --no-pager | tail -50--no-pager 是把输出直接打到终端不进入分页模式配合 tail 只取最后 50 行。看的时候重点盯 terminated、failed、Permission denied 这些关键词。第三步检查配置文件语法。对于 Nginx、Apache 这类有自己配置文件的软件启动失败最常见的原因是配置语法错误nginx -t很多软件都提供了类似 -t 的配置自检参数跑一下就能定位到是哪一行配置写错了。第四步看端口和权限。服务绑定的端口是否被占用工作目录或者日志目录的属主和属组是否正确。很多服务以专用用户身份运行如果它需要写某个文件但目录权限不对启动会直接失败。第五步用手动方式前台启动。把 ExecStart 里的命令复制出来直接在当前终端跑看它会报什么错/usr/sbin/nginx这个办法能绕过 systemd 的包装直接看到程序的原始输出很多被 systemd 吞掉的错误信息会立刻暴露出来。6.3 配置文件改坏了怎么恢复还有一种高频场景是你改了服务的配置文件然后 restart 服务发现服务起不来了。这种情况下如果你清楚自己改了哪个文件最快的办法是先把文件改回来再重新启动。如果你不确定是哪个文件的语法问题也可以在 systemd 层面临时降级处理——把服务停掉避免它反复重启刷日志。这里有一个小技巧systemctl restart 一个服务失败后你还可以用 systemctl try-restart它只会在服务已经在运行的情况下才尝试重启避免服务本来就停着却因为 restart 报错制造更多噪音。它其实更适合在日常操作中使用。7. 常见问题与排查技巧实录7.1 问题一service 文件改了重启为什么还是旧配置这个问题太典型了。很多新手改了 /usr/lib/systemd/system/ 里的 unit 文件然后直接 systemctl restart 服务发现配置根本不生效。原因很简单systemd 的主进程在系统启动时就把 unit 文件加载到内存里了你改了磁盘上的文件它的内存副本不会自动更新。正确做法是修改完 unit 文件之后先执行systemctl daemon-reload然后再 restart。如果不执行 daemon-reload你甚至可能在 restart 时报错提示你 unit 文件已经变了、需要 daemon-reload。这个命令的本质是重新加载 systemd 的 unit 定义文件安全起见每次改完 unit 配置都先跑一遍。注意daemon-reload 是无害的它在业务低峰期执行也不会影响正在运行的服务因为它只重载配置定义不会中断任何进程。所以大胆用。7.2 问题二服务一直处于 activating (auto-restart) 状态这种状态看起来就像服务在“反复启动、反复失败”。systemd 检测到服务退出后按 Restart 策略拉它但它又立刻失败退出形成死循环。通常的原因是启动命令本身有问题比如脚本里面的路径不存在、可执行文件缺少执行权限、程序依赖的配置文件格式错误。排查方法和前面说的启动失败路径一样先 journalctl -u xxx -b 看日志再看脚本里有没有语法错误。注意一个容易被忽视的点如果你在 ExecStart 里用了相对路径systemd 不一定能找到。ExecStart 里的路径必须是绝对路径。另外脚本里的环境变量不会自动继承——systemd 启动服务时不加载用户的 shell 环境如果你依赖了某个环境变量要么在 [Service] 段里用 Environment 明确指定要么直接写死。7.3 问题三journald 日志突然没了或者特别少这种情况通常是你执行了清理操作或者日志轮转策略太激进。journald 默认对日志占用的磁盘空间有限制达到上限会自动清理最旧的日志。查看当前日志占用情况journalctl --disk-usage如果发现占用很小可以检查 /etc/systemd/journald.conf 里的 SystemMaxUse它的单位是 bytes默认通常是文件系统的 10%。你可以按需调大或调小。还有一个常见问题是日志里只有内核日志、没有应用日志这通常是因为你的服务程序把日志打到了自己的日志文件里而不是标准输出/标准错误。journald 只能捕获进程写到 stdout/stderr 的内容程序内部用 log4j 之类的日志框架写到文件的内容它管不到。这是两种不同的日志通道理解这一点能减少很多困惑。7.4 问题四systemctl list-units 看不到自己刚创建的服务这个原因特别简单list-units 默认只显示当前正在运行或者已经加载到内存里的 unit你刚创建的服务如果还没启动过它就是“未加载”状态list-units 自然看不到。想看所有可用 unit用 list-unit-files。如果是刚创建的 unit你还没执行 daemon-reloadsystemd 甚至不知道这个文件的存在所以顺序永远是先 daemon-reload再 list-unit-files 确认系统认识它再 start。7.5 团队协作场景下的一个小建议如果你是团队里负责维护基础镜像或者需要向别人交付服务配置的人还有一个优化建议写 unit 文件时把 Description 写得足够清楚把注释写在文件里。这样团队里其他人 systemctl status xxx 的时候一眼就能从描述里看出这个服务是干什么的、由谁维护的。这个习惯在工作环境里非常重要因为你会离开一个项目代码会移交但服务器会一直运行下去。8. 从 RH124 到生产环境这一章内容的实际分量学完这一章你的能力边界已经从“会操作文件”扩展到了“能管理一个系统服务的生命周期”。这背后的分量比你想象的更重。你现在应该能回答这几类问题了系统开机时通过什么机制拉起服务、服务之间如何表达依赖关系、服务出问题之后去哪找日志、怎么把日志时间范围缩到精确的某几分钟。这些能力恰恰是系统管理员和生产运维工作的地基。如果你是为了考试在复习我的建议是你别只背命令最好找一台虚拟机把 Nginx 或者 httpd 的手动部署、服务注册、开机自启、日志查看整个流程完整地走一遍。考试题目再怎么变化底层考核的就是你能不能在一个陌生的 Linux 环境里快速把服务拉起来、确认它能开机自启、并且学会在组件出问题后定位原因。这个过程和我在第六节里带你的实操流程是完全一致的。我在实际培训中发现很多人学 systemd 最大的障碍不是内容难而是练习太少。因为 systemctl 命令本身没什么难度真正的难点在于你对 systemd 的架构有没有建立直观感受。你只有亲手创建一个 unit 文件、亲手把它 enable然后在 /etc/systemd/system 下看到那个符号链接你才真正理解 enable 的本质是什么。所以你如果只做了一件事我希望是第六节的实操——把整个流程跑通这个收获远大于你把 systemctl 的参数表背十遍。最后再分享一个小技巧写自己的测试服务时别直接拿生产环境的服务来练手最好自己写一个简单的 shell 脚本比如每五秒向一个日志文件写入一行时间戳然后把这个脚本变成服务。这样你可以在一个完全无害的环境里反复测试启动、停止、重启和各种异常场景学到的东西反而更扎实。等这套流程玩熟了生产环境里的服务在你看眼里就不再神秘了。