刚接手一批新服务器的时候，我最怕听到的一句话就是：机器重启之后起不来了。明明昨天还好好的，就因为装了个软件、改了行配置、或者单纯是机房断电后来电，系统就卡在一个黑屏、一个 grub> 提示符、或者一串 kernel panic 日志面前。这种时刻最能检验一个运维的底子——你到底懂不懂 Linux 从按下电源键到登录提示符之间发生了什么，懂不懂系统里的服务是怎么被拉起来的。今天我把这块内容完整梳理一遍，覆盖引导过程的每个阶段和 systemd 服务控制的日常操作，穿插一些我在真实环境里踩过的坑和排查思路，希望对正在学 Linux 或者被这类问题折磨过的朋友有帮助。
1. 引导过程拆解：从按下电源键到登录提示符
先别急着敲命令，我们把引导链路当成一条流水线来看。Linux 系统的启动不是“开机”这个动作本身就完成的，它由固件、引导加载器、内核、initramfs 和 systemd 五个环节接力完成。任何一个环节出了问题，都会以不同的症状表现出来。理解这条链路，是你后续做故障排查的地图。
1.1 固件与引导加载器：BIOS/UEFI 怎么找到系统
按下电源键之后，第一步不是 Linux 在工作，而是主板固件在干活。传统 BIOS 和现代 UEFI 在这一点上逻辑不同，但目标一致：找到可引导的介质，把控制权交给引导加载器。
BIOS 时代，固件按照 CMOS 里设定的启动顺序去扫描硬盘的第一个扇区（MBR，主引导记录），这个扇区只有 512 字节，里面包含 446 字节的引导代码和 64 字节的分区表。MBR 里的引导代码通常是 GRUB 的第一阶段（stage1），它干不了什么复杂的事，唯一的使命就是定位并加载 GRUB 的核心程序（stage2）。如果 stage2 因为文件损坏、位置移动或者分区表错乱导致读不到，你看到的就是一行grub rescue>提示符。
UEFI 则完全走了另一条路。它不需要 MBR，而是直接读取 ESP（EFI 系统分区）里的.efi引导文件，比如/boot/efi/EFI/centos/grubx64.efi。UEFI 固件里的 Boot Manager 维护着一份启动项列表，你可以用efibootmgr命令查看和调整这些启动项。这里值得注意，UEFI 模式下 GRUB 就不需要所谓“写入 MBR”的安装方式了，因为它本身就是作为 EFI 应用程序被固件直接加载的。
无论哪种方式，最终交到 GRUB 手里的工作是一样的：读取配置文件/boot/grub2/grub.cfg（CentOS/RHEL 系列，Debian/Ubuntu 是/boot/grub/grub.cfg），显示引导菜单，然后根据你选择的菜单项加载对应的内核vmlinuz-*和内存盘镜像initramfs-*.img，再把控制权交给内核。
实操提示：通过
grub2-editenv list可以查看 GRUB 环境变量，比如saved_entry记录了上次启动的菜单项。排查引导问题时，saved_entry指向一个不存在的内核版本，也是常见故障原因之一。
关于 GRUB 本身我后面有专门一节讲配置和修复，这里先记住一个核心结论：固件负责“找”，GRUB 负责“选”，内核负责“活”。
1.2 内核与 initramfs：系统是如何“活过来”的
GRUB 把vmlinuz-5.14.0-284.el9.x86_64和initramfs-5.14.0-284.el9.x86_64.img加载进内存后，控制权就交给了内核镜像。此时内核解压自身、初始化 CPU、内存管理、中断控制器等最基本的硬件环境，然后展开 initramfs——这个过程值得多说两句。
很多人不理解为什么 Linux 启动必须带一个 initramfs，根文件系统不是在硬盘上吗？答案是：内核最开始连硬盘都没法访问。SATA 控制器驱动、NVMe 驱动、USB 驱动、还有 LVM 和 LUKS 加密的映射逻辑，都是一些位于根文件系统/lib/modules/里的内核模块，而内核要访问这些模块的前提是……它得先能读取根文件系统。这是一个先有鸡还是先有蛋的问题。initramfs 就是打破这个循环的“随身行李”：GRUB 先把这个小型的临时根文件系统加载到内存里，内核解压后在其中运行 init 脚本，加载必要的存储驱动，然后才真正挂载实际的根文件系统，最后switch_root切换过去。
把它类比成出差——你不能等到了酒店再收拾洗漱包，你得在登机前就把洗漱包带在身上，initramfs 就是那个提前打包好的洗漱包。这也是为什么你在lsinitrd或lsinitramfs里能看到一堆磁盘驱动模块。
如果内核找不到根设备，或者 initramfs 里的驱动跟你机器的硬件不匹配，就会出现经典的挂载失败，屏幕上直接告诉你Failed to mount /sysroot或者unable to mount root fs，这就是引导阶段最经典的内核 panic 类故障。我在虚拟机里遇到过类似的情况，后面故障排查章节会展开讲。
1.3 systemd 接管：第一个用户态进程的使命
内核完成硬件初始化和根文件系统挂载，并按需执行 initramfs 里的/init脚本后，最终会调用真正操作系统里的第一个用户态进程。在 SysV init 时代它是/sbin/init，在 systemd 时代它是/lib/systemd/systemd，内核通过/sbin/init这个符号链接去找到它。
这个进程的 PID 永远是 1，是所有其他进程的祖先，也是系统管理的中枢。systemd 一旦运行，会根据/etc/systemd/system/和/usr/lib/systemd/system/里的 unit 文件来确定要启动哪些服务、以什么顺序启动、哪些并行启动。它的核心创新在于“按依赖关系并行启动”：传统 init 脚本是串行的，一个脚本跑完才跑下一个，开机时间按脚本数量线性增长；systemd 通过 unit 之间的After、Before、Requires、Wants等声明构建了一张依赖图，只要没有依赖约束的服务全部并行拉起，瓶颈只有在那些真正需要顺序的服务之间。
这里也要顺带提一句 target 的概念。systemd 用 target unit 来表示系统运行到某个状态，而不是传统意义上的“运行级别”。multi-user.target对应以前运行级别 3，graphical.target对应运行级别 5，reboot.target对应重启，poweroff.target对应关机。你可以用systemctl list-dependencies multi-user.target看这棵树长什么样。启动阶段 systemd 默认会拉起default.target，它通常是一个指向graphical.target或multi-user.target的软链接。
整个引导链条到这里还没结束，后面还有登录管理器、getty 终端、网络服务、SSH 等一大堆服务被 systemd 拉起。不过从架构上讲，到 systemd 接手，引导过程的主体已经完成，剩下的就是服务控制的主场了。
2. GRUB2 配置与内核参数调整：你能直接控制的引导变量
引导过程对普通运维来说，最常接触的入口就是 GRUB。它既是故障高发区，也是我们调整启动行为的落脚点。这一节重点讲 GRUB2 的配置生成机制、常见内核参数的含义，以及几个我们日常会遇到的修改场景。
2.1 grub.cfg 是怎么生成的？改配置别直接改文件
先说一个我见过很多次的错误操作：新手直接编辑/boot/grub2/grub.cfg，改完重启发现根本没生效，或者生效了但下次生成配置时被覆盖，白改。因为grub.cfg是生成文件，不是源文件。Debian/Ubuntu 的生成逻辑是update-grub（它内部本质是调用grub-mkconfig），CentOS/RHEL 有等价的命令，叫grub2-mkconfig，用法通常是：
grub2-mkconfig -o /boot/grub2/grub.cfg它的输入来源是/etc/default/grub和/etc/grub.d/目录下的脚本。你真正应该改的是这两个地方。核心的GRUB_CMDLINE_LINUX变量用来指定要传给内核的引导参数，GRUB_DEFAULT决定默认启动哪个菜单项，GRUB_TIMEOUT决定停留几秒让用户选择菜单。举个例子，我的一台老机器曾经每次开机花屏，后来发现在内核参数里加上nomodeset就能关掉早期的 KMS 模式设置，绕过显卡驱动初始化失败的问题。这个参数的修改路径很典型：
# 编辑 /etc/default/grub 里的这一行 GRUB_CMDLINE_LINUX="rhgb quiet nomodeset"修改后重新生成配置文件。对于 UEFI 机器别漏掉第二步更新。
这里也提一句，不少发行版默认的引导菜单里有多个内核版本（比如升级内核后旧内核还在），GRUB_DEFAULT=saved表示记住上次选中的菜单项，配合GRUB_SAVEDEFAULT=true在下次启动时默认选择与上次相同的菜单。有时候升级内核后系统自动选了新内核导致某个驱动异常，回滚到旧内核最快的方式就是开机时在 GRUB 菜单里手动选择旧版本，然后它会被“记住”，下次默认就用旧的。
2.2 常用内核引导参数与使用场景：从 quiet 到 rd.break
内核引导参数是排查引导问题时的重要武器。几个我实际用过、频率非常高的参数：
quiet：减少内核输出的日志信息，把滚屏过程隐藏起来。很多桌面发行版默认带这个参数，它和故障排查有着相反的诉求——排查时需要的是信息量，不带才是标准姿势。rhgb：Red Hat 图形化引导界面，相当于百叶窗进度条。这个参数在排查时同样建议暂时去掉，因为误导你看起来“卡住了”，实际上可能只是在等待某个网络服务超时。nomodeset：禁用内核模式设置（KMS），适用于显卡驱动初始化失败导致的黑屏或花屏，排查图形问题必试。rd.break：中断 initramfs 阶段的执行，进入一个紧急 shell。这个参数在忘记 root 密码需要重置场景下极其好用。进入后根文件系统还没被正式挂载成读写状态，你需要手动mount -o remount,rw /sysroot然后chroot /sysroot，再执行passwd root修改密码。systemd.unit=emergency.target或systemd.unit=rescue.target：让 systemd 跳过绝大多数服务，直接进入紧急维护模式或救援模式。跟单用户模式类似但不完全一样，emergency 模式下只有最基本的文件系统挂载，rescue 模式会尝试挂载所有本地文件系统。console=ttyS0配合earlyprintk=ttyS0：在服务器没有显示器只有串口的情况下，把内核日志和引导信息输出到串口。真实机房场景中，排查无显示输出的机器，这是唯一能看到引导信息的方式。
2.3 新内核引导失败的回退与 GRUB 救援模式
最后简单说回退。如果某次重启后内核 panic，但 GRUB 菜单还能显示，那就容易处理：开机菜单选择旧内核。如果系统自动选了新内核导致问题，可以启动时在菜单里切到旧版本后，进入系统执行grub2-set-default 0修改默认项，或者写GRUB_DEFAULT=0指定菜单项序号。
如果连 GRUB 菜单都进不去了，卡在grub rescue>提示符，那说明 GRUB 的主程序或配置文件找不到了。常见诱因是/boot分区损坏、分区被重建、或者是双系统安装 Windows 后把 MBR 覆盖了。修复思路一般是通过系统安装介质（ISO 进入救援模式或 LiveCD）chroot 进系统，重新安装和生成 GRUB。我后面故障排查那一节会给出具体的命令组合。
3. systemd 服务控制：从入门到实战的完整操作
引导完成后，系统中会出现几十个正在运行的服务进程。管理系统服务和排查服务故障，是 Linux 运维的日常主战场。这一节围绕 systemd 展开，先讲清楚它为什么能替代 SysV init，然后把 systemctl、journalctl 和自定义服务单元这些实操内容完整过一遍。
3.1 SysV init 到 systemd：为什么要换？
在 systemd 出现之前，Linux 使用 SysV init 风格的启动脚本体系。每个服务有自己的启动脚本，放在/etc/init.d/里，脚本通过start、stop、restart之类的参数被调用，运行级别通过/etc/rc.d/rc3.d/下面的一堆软链接来控制服务的启停顺序。这种方式的优点是简单直观，缺点是串行启动，一个服务等一个服务，慢；还有一个致命弱点，就是没有统一的服务监控机制。服务进程挂了不会被自动拉起，也没有日志统一采集，排查问题要在/var/log/下面一个个文件翻，效率很低。
systemd 的引入解决了这几个核心问题：
- 并行启动：服务之间通过依赖关系声明来调整，不依赖的服务并行拉起，系统启动时间大幅缩短。
- 单元化：所有服务、挂载点、设备、定时器、套接字都被抽象成 unit 文件，统一通过 systemctl 命令管理。
- 守护进程主动化：systemd 作为 PID 1，负责进程的分发、回收和监控。服务如果退出，systemd 可以根据 Restart 策略自动拉起来，相当于给每个服务加了一道保险。
- 日志整合：journald 收集系统的所有结构化日志，同一时间轴查看不同服务日志变得非常轻松。
- 更精确地管理依赖：比如
network-online.target可以让 SSH 只在网络真正就绪后才启动，而不是像旧系统那样 SSH 启动后网卡还在等 DHCP。
这套设计也带来了一个代价：学习曲线变陡。unit 文件的语法、target 的层级、各种状态机的定义都需要理解。但一旦过了这道坎，日常管理的效率提升是很明显的。
3.2 systemctl 常用操作速查：这些命令覆盖 80% 场景
日常工作中，systemctl的高频操作可以整理成一个速查表。我建议直接贴到你的笔记里，用多了自然就熟了：
| 操作 | 命令 | 示例 |
|---|---|---|
| 启动服务 | systemctl start 服务名 | systemctl start sshd |
| 停止服务 | systemctl stop 服务名 | systemctl stop nginx |
| 重启服务 | systemctl restart 服务名 | systemctl restart docker |
| 重新加载配置 | systemctl reload 服务名 | systemctl reload nginx |
| 查看运行状态 | systemctl status 服务名 | systemctl status sshd |
| 开机自启 | systemctl enable 服务名 | systemctl enable nginx |
| 取消开机自启 | systemctl disable 服务名 | systemctl disable nginx |
| 查看所有已加载服务 | systemctl list-units --type=service | 排查服务是否加载 |
| 查看开机自启列表 | systemctl list-unit-files --type=service | 查看 enabled / disabled |
| 掩盖服务（禁止任何人启动） | systemctl mask 服务名 | systemctl mask firewalld |
| 查看服务进程的依赖隐患 | systemctl list-dependencies 服务名 | 确认谁依赖谁 |
这里要注意两个特别容易混淆的概念：
restart与reload：restart 是完全终止进程再重新拉起，会造成服务中断；reload 是向进程发送 SIGHUP 信号让进程自己重新读取配置文件，全程无中断。像 nginx、sshd 这类支持优雅重载的服务，日常修改配置后应该用 reload 而不是 restart。但 reload 成功与否取决于进程是否支持这个信号处理，不支持reload的配置会直接报错。enable与start：enable 只负责设置开机自启的软链接，不会启动当前状态；start 只负责立即运行，不会修改自启状态。两个命令通常一起执行，写成systemctl enable --now nginx可以一步完成。
3.3 从零编写一个 Systemd Service：真实案例
很多第三方的软件安装包并不会自动注册 systemd 服务，比如你自己编译的二进制程序、用 Python 写的后台任务、跑在容器外的 Java jar 包，都需要手动编写 service 单元。这里用一个我常用的例子来说明格式。
假设我有一个 jar 包应用/opt/myapp/app.jar，需要在系统启动后运行，监听 8080 端口，日志写到/var/log/myapp/，进程崩了要自动重启。我会创建/etc/systemd/system/myapp.service：
[Unit] Description=My Java Application Service After=network-online.target Wants=network-online.target [Service] Type=simple User=myappuser Group=myappgroup WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -Xms256m -Xmx512m -jar app.jar ExecStop=/bin/kill -s TERM $MAINPID Restart=on-failure RestartSec=5 StandardOutput=append:/var/log/myapp/out.log StandardError=append:/var/log/myapp/err.log [Install] WantedBy=multi-user.target逐个解释关键字段的取舍。Type=simple是最常见的类型：systemd 把 ExecStart 里命令直接 fork 出来的进程当作主进程。如果程序有 daemonize（fork 到后台）行为，就得配合Type=forking并指定PIDFile，否则服务状态会一直显示 active (running) 但进程不是。
After=network-online.target表示这个服务要等网络完全就绪后再启动，否则 Java 程序如果在启动时尝试绑定端口或连接数据库，网络没起来就可能失败初始化。Wants和After的区别是：After 只是顺序约束，Wants 是弱依赖——如果 network-online.target 起不来，我们不强制让服务失败，但服务不能先于网络就绪。
Restart=on-failure只在非正常退出时自动重启，正常停止（比如手动 stop）不会触发自动拉起，这是生产环境比较合理的策略。另一个选项是always，它会在任何退出原因下都重启，包括被systemctl stop停掉——这种情况用起来非常容易困惑，因为你会发现服务一直“停不掉”。所以除非有特殊需求，我建议on-failure加RestartSec=5组合，避免服务崩溃后无限快速重启消耗 CPU。
写完后执行systemctl daemon-reload重新加载 unit 文件，然后用systemctl enable --now myapp启动并设置自启。这里容易踩的坑是：修改了 service 文件后如果忘记daemon-reload，systemctl start会报一个相当有迷惑性的错误，提示你找不到 unit 文件或字段不合法，其实只是新内容没有被 systemd 读取。
3.4 journalctl 日志查看：别再翻 /var/log/messages 了
systemd 整合了 journald，所有服务和系统日志都通过journalctl查询。基础操作：
# 查看某个服务的所有日志 journalctl -u nginx # 查看最近 30 分钟的日志 journalctl --since "30 min ago" # 跟踪实时日志（类似 tail -f） journalctl -f -u nginx # 查看本次启动之后的日志（排查启动问题神器） journalctl -b # 查看上次启动的日志（用于研究刚才为什么起不来） journalctl -b -1 -u nginx # 查看某个 PID 的日志 journalctl _PID=12345我在排查启动超时问题时，最常用的命令就是journalctl -u 服务名 -b加--no-pager，一眼看到服务在哪个阶段卡住。需要提醒的是，journald 默认的日志存储在内存和/var/log/journal/中，如果没有把日志持久化，重启后上一次启动的日志就丢了。要开启持久化，创建/var/log/journal目录即可，journald 会自动识别并持久化。生产环境的服务器，日志目录的挂载空间别忽略。
4. 引导与服务故障排查实录：真实案例与修复步骤
知识储备到位后，来点实战。这一节整理了几个我再三遇到的故障场景，每个都给出排查思路和最终修复方案。这些案例对应了许多热词里提到的“linux系统故障案例”和“linux运维故障案例”，都是从实际工作里沉淀出来的。
4.1 引导阶段故障：内核 panic 与 initramfs 损坏
先看一个我最近处理过的虚拟机案例。某台 CentOS 9 虚拟机，机房断电后重启，控制台显示error: file '/boot/initramfs-5.14.0-284.el9.x86_64.img' not found，卡在 GRUB 菜单或直接进入 grub rescue 模式。排查思路是这样展开的：
第一次现场判断：这个报错信息聚焦在 initramfs 文件缺失，大概率是/boot分区文件损坏、误删或者升级内核时写入失败。如果是误删还好办，重装 initramfs 即可。但更要担心的是磁盘有坏道导致文件静默损坏。我的排查顺序是：
- 进入 GRUB 菜单选择旧内核，看能否正常启动。如果能，说明只是新内核对应的 initramfs 有问题，需要在系统内重新生成。
- 如果所有内核都启动失败，就要警惕文件系统层面或硬件层面的问题。
- 从安装 ISO 启动进入救援模式，检查
/boot分区的文件系统完整性。
对于 initramfs 文件缺失但文件系统正常的情况，修复手段很直接。进入到 rescue 模式或 LiveCD 后 chroot，执行对应发行版的 initramfs 重建命令：
# CentOS / RHEL dracut -f /boot/initramfs-$(uname -r).img $(uname -r) # Debian / Ubuntu update-initramfs -c -k $(uname -r)如果/boot分区满也会导致内核升级时写入失败，但旧内核已经在新系统里了，问题在别处。另一个高频场景是挂载根文件系统失败，报unable to mount root fs或Failed to mount /sysroot。这种情况通常不是 initramfs 的问题，而是 initramfs 里 SATA/NVMe/LVM 驱动缺失，或者根设备名发生了变化。比如一块盘从sda变成了sdb，根设备 UUID 没变但因为 BIOS 枚举顺序变了导致盘序变化，GRUB 配置里的根设备 UUID 又对不上，内核就找不到根。此时可以故意进入 GRUB 菜单按e编辑引导项，在linux行末追加rd.break或直接指定根设备参数，比如改成root=/dev/sdb2，成功启动后再把 GRUB 的根设备配置改成 UUID 形式。
4.2 GRUB 被覆盖后的救援流程：Windows 与 Linux 双系统的经典场景
另一个经典故障是双系统机器安装了 Windows 后，MBR 里的 GRUB 引导代码被 Windows Boot Manager 覆盖，重启后直接进 Windows，Linux 分区完全消失了。这类问题的修复流程非常固定，思路就是：用 Linux 安装介质引导 → chroot 进入原 Linux → 重新安装 GRUB。
假设你的 Linux 根分区是/dev/sda2，/boot是独立分区是/dev/sda1，流程大致是：
# 启动安装介质后打开终端 mkdir /mnt/sysroot /mnt/boot mount /dev/sda2 /mnt/sysroot mount /dev/sda1 /mnt/sysroot/boot # 如果用了 LVM 或需要网络，先激活环境 mount --bind /dev /mnt/sysroot/dev mount --bind /proc /mnt/sysroot/proc mount --bind /sys /mnt/sysroot/sys # chroot 进入原系统 chroot /mnt/sysroot /bin/bash # 重新安装 GRUB 到 MBR grub2-install /dev/sda # 重新生成引导配置文件 grub2-mkconfig -o /boot/grub2/grub.cfgUEFI 模式下则不太一样：不需要往 MBR 里装引导代码，而是重新安装 EFI 引导项：
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB efibootmgr -c -d /dev/sda -p 1 -L "GRUB" -l '\EFI\GRUB\grubx64.efi'一个容易忽略的坑在 chroot 之前。如果原系统的/boot是独立分区，需要在 chroot 之前挂载好；如果是/boot/efi独立 ESP 分区，那需要注意挂载路径。好几次我都是因为忘了 bind mount/dev，导致 chroot 后grub2-install报找不到设备节点，排查方向完全跑偏。
4.3 服务启动故障：超时、循环重启与依赖循环
引导问题之外，服务层面的故障占运维工作量的大头。我把它按症状分为三类：
第一类是“启动超时”。典型报错是Job for nginx.service failed because a timeout was exceeded。这类问题通常不是服务本身真的在耗时间，而是 systemd 在启动过程中卡在了某个前置条件上。比如 unit 文件里写了After=network-online.target，但这个 target 依赖的NetworkManager-wait-online.service长时间等待 DHCP 超时，那么网络 target 迟迟不进入 active，依赖它的所有服务全部排队卡死。排查手段是systemctl status network-online.target看它为什么 pending，或者干脆把某些服务的After=network-online.target改成After=network.target，因为对于大多数服务来说，网卡已配置就够用了，不需要等待在线状态确认。
第二类是“服务循环重启”。日志里不断刷start request repeated too quickly，然后 systemd 放弃启动。这种现象通常发生在服务脚本本身有问题，比如程序启动后立刻退出、配置文件语法错误、或者依赖的目录/用户不存在。排查方法就是看journalctl -u 服务名的报错，同时手动运行进程看报错输出。我曾经遇到一个情况，是 Java 服务里 jar 包路径写错了，导致每次启动秒退，systemd 反复拉起，把/var/log/messages刷得飞快——RestartSec=5都没写，默认的快速重启让 CPU 占用率短时间飙升。
第三类是“服务间死锁或依赖循环”。systemd 本身能检测到依赖循环（ordering cycle），遇到这种会直接报冲突。更隐蔽的是服务 A 需要服务 B 的某个接口，而 B 又在等 A 启动完成的间接依赖。排查这种问题靠systemd-analyze critical-chain查看启动瓶颈，和systemd-analyze plot画一张启动时间线图，找等待原因。
4.4 常见问题速查表：引导与服务故障对照手册
把以上经验整理成一个快速对照表，适合贴到运维手册里：
| 故障现象 | 最可能的原因 | 快速定位命令 | 修复方向 |
|---|---|---|---|
| 卡在 grub rescue 提示符 | GRUB stage1 无法加载 stage2 | 看提示符路径 | 修复 GRUB / 重装引导 |
| 提示 initramfs 文件缺失 | /boot 分区损坏或误删 | lsinitrd 验证 | dracut / update-initramfs 重建 |
| kernel panic: unable to mount root fs | 根设备找不到或驱动缺失 | 编辑 GRUB 手动指定 root | 改 UUID / 重建 initramfs |
| 开机黑屏无响应 | 显卡驱动 KMS 初始化问题 | 内核参数加 nomodeset | 临时验证后持久化配置 |
| 忘记 root 密码 | 需要进入维护模式 | rd.break | chroot 后 passwd 修改 |
| 服务起不来报 timeout | 前置 target 等待超时 | journalctl -b -u 服务名 | 调整 After 依赖或网络等待 |
| 服务重复快速重启 | 程序本身秒退 | journalctl -u 服务名 | 检查 ExecStart 路径和配置 |
| 服务已 enabled 但未运行 | 上次启动失败被 systemd 标记 | systemctl status 服务名 | 检查状态失败原因修复后重启 |
5. 引导优化与服务参数的进阶调优
故障排查是补救，优化是预防。这一节聊一些平时容易被忽略但实用价值高的参数调整思路，从内核启动参数的精简到 systemd 默认超时时长的调整。
5.1 内核参数与启动时间的优化思路
很多桌面发行版默认带有rhgb quiet，这两个参数其实是把启动过程包装成“漂亮的黑屏”，但如果你仔细分析启动时序图，会发现图形化启动本身其实占了不少启动时间。服务器上建议去掉。用systemd-analyze可以查看整体启动时间，用systemd-analyze blame可以查看每个 unit 的耗时排序，快速找出启动瓶颈。
一个我实践过的典型优化案例：某台服务器启动时间高达 3 分钟，用blame一看，排名第一的是某个挂了 NFS 挂载点的服务，它尝试挂载一个不可达的远端 NAS 时超时等待 90 秒。优化方法是调整 NFS 挂载参数，加上x-systemd.device-timeout=30或者把挂载配置改为_netdev并降低等待时间。这类问题的本质是 systemd 对慢速设备（网络存储）的挂载等待时间默认太长，你以为系统卡死，实际上它在耐心等待一个永远等不到的网络设备。
另外，如果在/etc/default/grub里给内核加mitigations=off可以关闭 CPU 漏洞缓解措施，换取少量性能提升，但这个在生产环境涉及安全取舍，不建议轻易改；nohz=off这样的参数直接影响内核调度器行为，非必要不动，保持默认即是最大安心。
5.2 systemd 服务的超时与并发设置
systemd 默认给服务启动设置了 90 秒（DefaultTimeoutStartSec=90s）、停止 90 秒（DefaultTimeoutStopSec=90s）。对于需要长时间初始化的服务，90 秒可能不够，会被 systemd 判断为超时强杀；对于正常的服务，90 秒又太长，停止服务时如果程序不响应 SIGTERM，你需要等待 90 秒才能被 SIGKILL 强行结束。这两种情况都可以通过在服务的[Service]段添加TimeoutStartSec和TimeoutStopSec来自定义。
我踩过一次很深刻的坑：某个 Python 服务停止时，明明在代码里写了优雅退出的逻辑，但因为某个数据库连接池没有关闭，SIGTERM 之后进程迟迟不退出，systemd 要等 90 秒才发 SIGKILL，导致每次重启这个服务都要白等一分半。后来我直接在 unit 文件里加了TimeoutStopSec=15，超过 15 秒直接强杀，配合服务内部处理，整体体验顺畅多了。这里有个原则：优雅退出要给足够时间，但别让等待时长掩盖了程序的 bug。如果你发现某个服务需要依赖自身很长的超时时间才能正常停止，那大概率程序里还有资源没释放干净，别只把参数调大就完事。
另一个进阶功能是服务间的并行度控制。systemd 允许你在一个 unit 文件里通过[Unit]段的JoinsNamespaceOf=把多个服务放进同一个命名空间，或者通过 CPUAffinity、MemoryMax 等 cgroup 资源控制参数限制服务占用。生产环境中，给关键服务设置MemoryMax=512M、CPUQuota=50%之类的限制，能有效防止某个异常服务进程把整个系统拖垮。这些内容属于 systemd 的资源控制纵深，有兴趣可以看systemd.resource-control的 man 文档。
最后再分享一点个人体会
我在实际排障过程中，每次被引导问题折磨得最惨的时候，回想起来都发现自己对链路理解不足。引导过程不是孤立的几个点，而是一条完整的链条：固件→GRUB→内核→initramfs→systemd→服务。任何一环报错，先判断它属于链条上的哪一环，再按对应环节去排查，思路就会清晰很多。
建议大家找个虚拟机做几次破坏性实验：在/etc/default/grub里写坏参数、删掉 initramfs 文件、用 dd 抹掉 MBR、给服务配置一个启动即退出的 ExecStart，然后亲手去修。这种练习比读十篇文档都有效。你真正在grub rescue>下慌过一次、在journalctl里翻到过关键报错之后，这套知识才是你自己的。以后遇到再奇怪的启动故障，你也会知道，问题大概率不是玄学，而是链条上某个细节没对上。
