聊到“引导过程与服务控制”，我脑子里第一个画面是上周处理的一台服务器：客户报障说机器重启后卡在登录界面进不去，远程网络也不通。我远程连到带外管理口一看，屏幕上赫然停着 GRUB 菜单，光标闪啊闪，但键盘敲什么都没反应。这种场景对搞过 Linux 运维的人来说应该都不陌生，问题要么出在引导加载器，要么出在 systemd 拉起服务的过程中。今天我想把这两个环节串起来，完整拆一遍：从固件自检到内核启动，再讲到 systemd 如何控制服务、决定开机该跑什么、服务挂了该不该拉起来。这篇内容适合刚接触 Linux 的运维新人，也适合那些已经在用 systemctl 但没搞明白底层逻辑的开发者。理解引导过程，能让你在机器起不来时知道去哪找问题；理解服务控制，能让你在服务频繁崩溃时做出正确的重启策略，而不是靠一把梭的 crontab。
1. 引导过程的整体设计与阶段拆解
1.1 为什么引导要分阶段：从固件自检到内核接管
很多人把“开机引导”当成一件特别神秘的事，其实把它拆开看，逻辑非常直白。整个启动过程像一场接力赛：固件跑第一棒，引导加载程序跑第二棒，内核跑第三棒，最后的 init 进程（现在绝大多数是 systemd）跑第四棒，之后所有用户态服务都归它管。每一棒只做自己分内的事，然后把控制权交给下一棒。
为什么非要分这么细？因为每一阶段的能力边界完全不同。固件（BIOS 或 UEFI）只知道怎么初始化硬件、怎么从磁盘上按固定规则找一段代码，它不理解文件系统是 ext4 还是 xfs，也不懂内核镜像文件是个什么结构。引导加载程序（GRUB2）则懂得去读配置文件、加载内核镜像和 initramfs 到内存。内核接管后，会先做硬件探测、内存管理初始化、驱动加载等乱七八糟的事，等基础环境就绪，才会去执行第一个用户态进程。这个时候 systemd 才登场。分阶段设计的本质，是让每一层职责单一、接口清晰，任何一个环节坏了，都能定位到具体是哪一棒出了问题，而不是一锅粥。
这个设计最直观的好处体现在排障上。如果机器根本没法上电或者自检报错，那是硬件或固件问题；如果卡在 GRUB 菜单，那是引导加载器出问题；如果内核 panic 或者挂载不了根文件系统，那是内核或 initramfs 问题；如果系统进了登录页但服务起不来，那才是 systemd 和服务的锅。层次分明，排查方向就不会乱。
1.2 传统 BIOS 与 UEFI 的差异：别再只看 MBR 和硬盘
引导过程的第一棒是固件。早期大家很熟悉的是 BIOS 加 MBR 的组合，主引导记录存放在磁盘第一个扇区，里面只有 512 字节，其中真正可执行的引导代码只有前 446 字节，后面是分区表和结束标志。因为空间太小，它干不了多少事，通常只能去加载 GRUB 的第二阶段。这种方式的限制很明显：MBR 最多只能有 4 个主分区，磁盘容量超过 2TB 之后就得靠 GPT，很多老主板对 GPT 的支持还很别扭。
UEFI 的引入把这些问题基本解决了。UEFI 固件会读取 EFI 系统分区（ESP）下的 .efi 文件，比如常见的 shimx64.efi、grubx64.efi。系统启动时，固件直接通过 EFI 引导条目去定位引导管理器，不再依赖磁盘第一个扇区的 512 字节。这带来的好处是更灵活、更安全（支持 Secure Boot），同时支持 GPT 和超大磁盘。现在新装的服务器和 PC，绝大多数默认就是 UEFI 模式。
不过这里有个实践上的坑：很多人在维护老机器或者迁移系统时，容易忽略固件模式和磁盘分区表的匹配问题。BIOS 模式下安装的系统，如果直接在 BIOS 设置里切成 UEFI，大概率引导不了；反过来也一样。我见过不少同事把磁盘从旧机器拆下来装到新机器上，发现系统起不来，第一反应是重新装系统，其实只要检查一下固件模式，或者进 GRUB 手动指定引导文件，就能救回来。所以拿到一台新机器，先确认它的固件模式，再决定后续引导修复的手段，能少走很多弯路。
1.3 GRUB 2 在引导过程中的真正角色
GRUB2 是目前绝大多数 Linux 发行版默认的引导加载程序，但很多人对它理解停留在“开机出现那个菜单的东西”。实际情况比这复杂一些。GRUB2 有自己的文件系统驱动，能识别 ext4、xfs、btrfs 这些常见文件系统，能读取 /boot/grub2/grub.cfg 配置文件，能加载内核镜像 vmlinuz 和 initramfs。它不是简单做跳转的，而是先按 grub.cfg 里定义的菜单项，把内核和 initramfs 读入内存，设置好启动参数，然后跳转到内核入口执行。
grub.cfg 看似复杂，但绝大多数情况下不需要手写。传统方式是修改 /etc/default/grub，然后执行 grub2-mkconfig -o /boot/grub2/grub.cfg（在 Debian/Ubuntu 系是 update-grub）。这个生成过程会自动扫描系统里的内核版本、探测系统盘参数、写入默认启动项等。很多新手容易犯的错误是直接修改 grub.cfg，结果下次内核更新或重新生成配置时，改动就丢了。正确做法是改 /etc/default/grub 这种源头配置文件，再生成。
还有一个细节要注意：GRUB 菜单里看到的启动参数，比如 quiet、splash、rhgb，不是随便写的。quiet 表示内核启动时减少输出，只显示重点日志；splash 是显示开机 logo 画面。这些参数在排查问题的时候往往会成为阻碍，因为内核早期报错信息会被安静模式吞掉。我每次遇到开机卡死的问题，第一件事就是在 GRUB 菜单按 e 编辑启动项，把 quiet 和 splash 删掉，然后看内核到底输出到哪一步才停，比瞎猜高效得多。
2. 引导过程核心细节与实操要点
2.1 动手改启动参数：进入单用户模式与急救环境
前面提到 GRUB 菜单按 e 可以编辑启动项，这是每个系统管理员都应该熟记的操作。在 GRUB 菜单界面，找到以 linux 开头的行，行尾通常跟着一串参数，类似 root=/dev/mapper/cl-root ro quiet。把光标移到 quiet 后面，删掉 quiet 和 splash，然后再看实际情况决定是否追加参数。
比如启动过程中内核 panic、根文件系统挂载失败，可以试着把 ro 改成 rw，让内核直接以读写方式挂载根分区，这样可以避免因为只读挂载导致 fsck 修不了文件系统。又比如你想直接进单用户/急救模式，可以在那行末尾加上 systemd.unit=rescue.target，或者干脆加上一个 s 或 single。注意不同发行版对单用户模式的支持细节有差异，CentOS/RHEL 7 之后用 systemd 管理，推荐明确指定 systemd.unit=rescue.target 或 emergency.target，而不是依赖传统的单用户关键字。
单用户模式是个很好的排障环境：网络通常是关的，不需要登录密码（但某些配置下会要求），可以直接操作文件系统。我通常用它来做这么几件事：修改 /etc/fstab 里错误的挂载项、重置 root 密码、修复被损坏的引导配置、手动执行 fsck。这里有个容易踩的坑：rescue.target 和 emergency.target 不是一回事。rescue.target 会尝试启动基本的系统服务，比如挂载本地文件系统、启动 network 可能不会；emergency.target 则更底层，几乎是只有根文件系统被只读挂载的最小环境，有点像“急救室”。如果你只是为了修文件，emergency 够用；如果你需要让网络和部分依赖环境就绪，用 rescue 更顺手。
2.2 initramfs：为什么内核不能直接挂载根文件系统
每次安装内核或者更新内核模块时，系统都会生成一个 initramfs 镜像，文件名形如 initramfs-5.14.0-362.el9.x86_64.img。它的作用常被低估。很多人以为内核可以直接读取硬盘上的根文件系统，其实在内核启动初期，它还没有加载对应磁盘控制器的驱动，也没有能力处理复杂的 LVM、LUKS 加密、mdraid 阵列。initramfs 本质上是一个临时根文件系统，里面包含了必要的内核模块、udev 规则、lvm/dm 工具等，让内核先在这个临时环境里把磁盘识别出来，把根文件系统准备好，再切换到真正的根分区上继续启动。
如果 initramfs 缺失或损坏，典型的故障现象是启动到某一步直接报“unable to mount root fs”或者 kernel panic。很多情况下不是内核坏了，而是 initramfs 没有把磁盘驱动打进去。比如你把系统从 IDE 接口迁移到 virtio 接口的虚拟机时，旧 initramfs 里没有 virtio_blk 驱动，自然找不到根分区。解决办法就是在旧环境里重新生成 initramfs：CentOS/RHEL 系用 dracut --regenerate-all --force，Debian/Ubuntu 系用 update-initramfs -u。生成前建议确认新硬件环境需要的驱动已经在系统里。
还有一个常见误区：initramfs 不是越新越好，也不是必须数量越少越好。如果你手动清理过 /boot 下老旧内核对应的 initramfs，不用慌，因为系统只会在当前内核缺失时才需要它。通常建议保留最近一两个内核版本的 initramfs，以防新内核启动失败时可以回退到旧内核。
2.3 systemd 作为第一个进程：引导的高潮部分
内核完成初始化后，最后一步是执行根目录下的 /sbin/init，在现代 Linux 发行版上它被符号链接到了 systemd。从这里开始，引导过程进入系统管理阶段。systemd 作为 PID 1，会读取默认的 target，也就是要进入的系统状态。这里可以理解为“开机后系统要进入哪个运行级别”。传统 SysV init 有运行级别 0 到 6，systemd 用 target 单元代替了它们，比如 poweroff.target 对应关机、rescue.target 对应单用户、multi-user.target 对应多用户命令行、graphical.target 对应图形界面。
systemd 启动过程不是简单按顺序执行一堆脚本，而是分析单元之间的依赖关系，构建执行事务。比如 multi-user.target 会依赖 basic.target，basic.target 又依赖 sysinit.target，sysinit.target 负责挂载文件系统、启动 udev、配置机器名等底层初始化。这些依赖可以通过 Wants、Requires、After、Before 声明，systemd 根据依赖图尽可能并行启动没有前后依赖关系的服务，这就是为什么开机速度比传统 SysV 脚本快很多。
在实际操作中，只要开机引导能走到 systemd 阶段，绝大多数“系统起不来”的问题都会变成“某个服务起不来”，排查思路会完全不同。如果你在引导参数里临时追加 systemd.unit=rescue.target，可以在不启动全部服务的情况下进入系统，但这种模式下很多基础服务缺失，比如网络和日志，所以只适合排障，不适合日常使用。我建议平时稳定跑 multi-user.target，特殊维护任务再用 rescue 或 emergency，不要图省事直接把系统默认 target 改成 rescue，否则下次重启你会发现自己进了一个什么服务都不跑的空壳系统。
3. 服务控制：从 systemctl 到开机自启的完整玩法
3.1 先把手上的命令熟起来：systemctl 高频组合
服务控制在 systemd 体系里就是围绕 systemctl 命令展开。核心操作其实就那么几个：systemctl start、systemctl stop、systemctl restart、systemctl status、systemctl enable、systemctl disable。但真正实操中会有一些组合值得养成习惯。比如启动服务的同时设置开机自启，可以写成 systemctl enable --now nginx，一步到位。停用服务并取消开机自启是 systemctl disable --now nginx。这个 --now 参数很实用，能少敲一条命令，也避免“启动了但忘了 enable，重启后服务丢了”这种尴尬。
再就是 mask 和 unmask。很多人分不清 disable 和 mask 的区别。disable 只是把开机自启的符号链接删掉，服务依然可以被手动 start；mask 则更狠，会把单元文件链接到 /dev/null，让服务彻底无法启动，无论是手动还是被其他服务依赖。这个操作适合用在明确不想让某个服务跑起来、又担心它被其他服务间接拉起的场景。比如服务器上有个不该启动的 firewalld，但它有时候会被其他服务触发，如果你用 disable 发现治不住，就可以直接 mask。
查看状态也有讲究。systemctl status 输出里包含很多信息，不止是“active (running)”这么简单，还有主进程 PID、内存占用、最近日志。新版 systemctl 默认截断输出，你可以加 -l 参数看完整内容。用 systemctl status --no-pager 避免长输出被卡在 less 里。对于排障，status 和 journalctl -u 服务名 -b 是最常用的组合，前者看服务当前状态，后者看本次开机以来的服务日志，两者配合基本能解决 80% 的服务起不来问题。
3.2 单元文件解剖：一个服务是怎么被拉起来的
服务对应的单元文件默认在 /usr/lib/systemd/system/ 或 /etc/systemd/system/ 下，前者是安装软件包时自带的，后者是管理员自定义或覆盖用的。两者优先级不同：/etc 下的同名文件优先级更高，可以覆盖包管理器带来的默认配置。这个机制非常关键，比如 nginx 官方仓库打包的 nginx.service 在 /usr/lib/systemd/system/nginx.service，你想加环境变量、调整启动超时，别去改原文件，只要在 /etc/systemd/system/nginx.service 里放一个覆盖文件，或者用 systemctl edit nginx 创建 drop-in 片段，既清晰又不怕软件升级覆盖。
单元文件的核心结构一般分三个部分：Unit、Service、Install。Unit 段描述服务本身和对其他单元的依赖关系，比如 After=network.target 表示在网络服务启动后再启动本服务，但这只是顺序上的保证，并不自动拉网络服务；而 Requires= 或 Wants= 才会真正把依赖的单元拉起来。差别在于 Requires 的依赖服务失败时本服务也会失败，Wants 则只是尽力而为。Service 段定义怎么启动、怎么停止、重启策略如何。ExecStart 是启动命令，注意它要求的是绝对路径，而且不像 shell 那样自动套一层解析，想用管道重定向得写成 /bin/sh -c '...'，这是新手很容易踩的坑。Install 段通常只有 WantedBy=multi-user.target，表示开启 enable 时会在 /etc/systemd/system/multi-user.target.wants/ 下创建符号链接，这就是开机自启的实现机理。
每次修改单元文件后，记得执行 systemctl daemon-reload，让 systemd 重新加载改动。我见过太多次同事改了 ExecStart 后不 reload，直接 restart 服务，结果 systemd 还在用旧配置，服务行为没变化，白白浪费时间排查。
3.3 用 target 管理一组服务：从 multi-user 到自定义划分
target 单元看起来像“组”，作用是聚合一组服务，以及定义系统启动后进入的状态。开机自启的本质不是“启动某个服务”，而是“把该服务的符号链接放进某个 target 的 wants 目录”。这带来一个非常实用的扩展思路：你可以创建自定义 target，把一组服务按业务归类，然后通过切换 target 或设置默认 target 来控制整组服务的启停。
举个例子：服务器上跑着 nginx、php-fpm、redis，三个服务属于同一个 Web 应用栈。你可以新建一个 webapp.target，写一个简单的单元文件，里面声明 Wants=nginx.service php-fpm.service redis.service，然后 systemctl enable webapp.target。之后想要整组启动就 systemctl start webapp.target，想全部停掉就 systemctl stop webapp.target。这种方式的优势是操作粒度更清晰，关机或重启时 systemd 会按 target 依赖统一处理。
target 之间本身也有依赖层级。multi-user.target 是大多数服务默认的 WantedBy，它本身又依赖 basic.target。而 graphical.target 会在 multi-user.target 基础上再加载显示管理服务。理解了 target 依赖，就能明白为什么 systemctl enable 某服务时提示创建了 symlink，却没说“开机启动”。因为 enable 只是“愿意被某个 target 拉起”，最终拉不拉要看那个 target 是否在启动路径上。如果你把默认 target 改成 graphical.target，但机器没装图形环境，启动时系统会尝试后失败并回退，浪费时间。
3.4 服务超时与重启策略：别让假死拖垮业务
服务控制不只是 start/stop/restart，更重要的是如何让服务在异常退出后自动恢复。我见过不少线上事故，最后定位到就是某个进程异常退出后没人把它拉起来。systemd 的重启策略参数能解决这个问题。Service 段里 Restart=on-failure 是比较推荐的折中方案，它只在服务非正常退出时才重启，正常 stop 不会触发重启。如果业务要求更激进，可以配 Restart=always，但小心陷入死循环。搭配 RestartSec=3 让 systemd 在重启前等 3 秒，给进程一点释放端口和资源的时间。
另一个常被忽略的是 TimeoutStartUSec 和 TimeoutStopSec。有些服务启动脚本特别慢，默认超时 90 秒根本不够，启动会被 systemd 直接杀掉。比如 Java 应用要做 JIT 预热、数据库要恢复大内存，建议在单元文件里把 TimeoutStartSec 调大，比如 300。停止时也一样，服务优雅退出可能超过默认的 90 秒，太长的话先收到 SIGTERM，等超时后收到 SIGKILL，进程没有机会清理，极端情况会留下脏状态。我个人的习惯是给 Web 类服务设置 TimeoutStopSec=30，给数据库或消息队列设置 TimeoutStopSec=120，再配合 KillSignal=SIGTERM，保证业务有足够时间完成退出动作。
资源限制也可以放在单元文件里。传统方式改 /etc/security/limits.conf 需要用户重新登录才生效，但 systemd 服务可以直接在单元文件里写 LimitNOFILE=65535、LimitNPROC=4096。对于生产环境，每台服务都应该明确设置文件描述符上限，否则高并发场景下很容易报 too many open files，而且这问题往往不好查，日志里未必有明确报错，只能靠肉眼观察和系统监控。
4. 引导和服务控制的常见问题与排查技巧
4.1 开机直接进急救模式：手动重建引导文件的正确姿势
不少人会遇到这种情况：开机后系统没有正常进入登录界面，而是弹出一个提示说进入了 emergency mode，让你输入 root 密码做维护。这通常是 /etc/fstab 里某个挂载项出了问题，或者文件系统损坏没有被自动修复。在提示界面输入 root 密码后，第一时间执行 mount -o remount,rw / 把根分区切到读写模式，否则后续修改都会被拒绝。
然后看 systemctl status mnt-home.mount 这类挂载单元的状态，或者直接执行 mount -a 试试能否重新挂载所有条目。如果是 /etc/fstab 里写了不存在的设备或错误的 UUID，注释掉那行或者修正参数，再执行 mount -a 验证。这里要特别注意：修改之前先把原文件备份，别手一滑删错关键条目。确认修改没问题后，执行 reboot，系统一般就能正常进入。
如果连 emergency 都进不去，GRUB 菜单选择旧内核版本或者用救援模式引导，再把 initramfs 重新生成一遍。手动重建引导流程看起来复杂，其实核心就是 chroot 进原系统根分区，然后按发行版重新生成 grub 配置和 initramfs。需要注意的是 chroot 之前要先把 /proc、/sys、/dev 挂载进去，否则很多命令行为异常。这个操作是每个运维都应该能在心里默写出来的基本功，而不是临时上网搜。
4.2 服务起不来的排查顺序：先日志后配置
服务启动失败这事太频繁了，但排查顺序如果对，三五分钟就能定位。我第一次遇到 nginx 起不来时，习惯先 systemctl status nginx，然后盯着 “Active: failed” 发愣，其实状态里通常已经带了错误日志。正确顺序是：第一，systemctl status 服务名 -l，看状态和最近几行日志；第二，journalctl -u 服务名 -b --no-pager，看本次开机以来的完整日志；第三，手动执行服务的启动命令，看前台输出的报错。很多服务，比如 nginx，手动运行 nginx -t 检查配置文件语法，能迅速暴露问题。
日志里常见的问题有几类：权限不足、端口被占用、二进制文件路径不对、依赖的数据库或缓存没起。端口被占用的典型报错是 bind() to 0.0.0.0:8080 failed (98: Address already in use)，这时候用 ss -tlnp 查谁占着端口，比盲目重启服务有用。权限问题则往往出现在日志目录归属不对、PID 文件目录不可写。如果服务是以自定义用户运行的，还需要确认工作目录和配置文件的读权限，systemd 不会帮你规避这些问题。
还有一类非常隐蔽的问题：服务明明配置了环境变量，运行时却读不到。检查单元文件里 Environment= 或 EnvironmentFile= 的写法，后者经常因为文件里出现特殊字符导致解析失败。调试这类问题，可以在 ExecStart 前加一个 /bin/sh -c 'env > /tmp/xxx.log', 这样能直接把运行环境打到临时文件里，非常直观。
4.3 开机太慢：systemd-analyze 帮你定位性能瓶颈
开机能进系统不代表没有问题，最常见的就是开机特别慢，卡在某一步一分钟以上。与其盲猜是哪个服务拖后腿，不如用 systemd-analyze 这组命令。systemd-analyze 直接给出从内核启动到用户态服务完成后总耗时，然后 systemd-analyze blame 会按耗时从高到低列出所有服务。systemd-analyze critical-chain 则展示关键依赖链路，告诉你哪条路径最拖时间，比如 network.service 耗时 20 秒，后面一堆服务都在等它。
按我的经验，开机慢的原因排名前三：网络服务等待超时、某个服务依赖了不存在的设备或挂载点、存在启动脚本里 sleep 的坏习惯。比如 NetworkManager-wait-online.service 在很多机器上会等待网络完全就绪，如果配置了自动获取 IP 但 DHCP 响应慢，就会卡很久。这种服务对无网卡或断网的机器简直是灾难。处理方式可以是 systemctl disable NetworkManager-wait-online.service，只要确认业务不依赖开机即联网就行。
另外，日志里如果出现很多 Failed to start xxx 的记录，可能不是真的失败，而是服务被 disable 或者 mask 掉了，systemd 记录为 failed 状态。这种噪音会误导判断。可以结合 systemctl list-units --failed 看当前失败单元清单，排除掉那些本来就打算停用的服务，再集中处理真正影响启动的单元。
4.4 引导与服务控制问题速查表
在实际排障过程中，把常见问题的症状、原因和解决办法快速过一遍，往往比现场翻文档高效。我自己整理过一份速查表，常年贴在笔记软件里，遇到类似场景直接对号入座。这里列几个高频项供参考。
| 症状 | 可能原因 | 处理办法 |
|---|---|---|
| 开机卡在 GRUB 菜单，无法进入系统 | 引导配置文件损坏、磁盘识别错误 | 按 e 检查 root= 参数是否指向正确分区；用引导救援模式重新生成 grub.cfg |
| 内核启动时报 Unable to mount root fs | initramfs 缺少磁盘驱动或根分区无法访问 | 用旧内核或救援盘进入系统，执行 dracut --regenerate-all --force 重建 initramfs |
| 进入 emergency mode | /etc/fstab 挂载项写错或文件系统损坏 | remount rw 后检查 fstab，执行 mount -a 验证；必要时 fsck 目标分区 |
| 服务 start 成功但 status 显示 inactive (dead) | ExecStart 命令执行后立即退出，或被 Type 设置误导 | 手动执行启动命令看报错；检查 Type 是 simple 还是 forking，forking 类型需指定 PIDFile |
| 服务一直处于 activating (auto-restart) | 启动命令通常在超时前没成功，systemd 反复重启 | journalctl 看日志；调大 TimeoutStartSec；检查启动脚本是否正确后台化 |
| enable 提示没有文件或目录 | 单元文件不存在，或 Install 段缺少 WantedBy | 检查 /etc/systemd/system 和 /usr/lib/systemd/system；补全 Install 段后 daemon-reload |
| systemctl 命令执行超时 | systemd 与系统通信异常，或者 PID 1 被 D 状态进程拖住 | 检查系统负载，排查不可中断 IO；必要时通过 sysrq 或带外控制台重启 |
这张表没法覆盖所有情况，但可以帮你建立一套快速定位的思维框架：先看状态，再查日志，最后动手改配置。每一步别跳跃，很多看起来复杂的故障，其实只是你在某个步骤上太心急。
5. 经验总结：给新手和实战者的建议
关于引导过程与服务控制，我个人的体会是：这两件事本质上是在处理“顺序”和“状态”。引导过程中每一步都有严格的先后依赖，服务控制里每一个依赖关系都决定了系统能不能稳定运行。初学阶段不要满足于会敲 systemctl start nginx，而是要搞清楚 start 背后发生了什么，enable 为什么只是创建符号链接，target 之间为什么有优先级。把这些底层逻辑吃透，遇到新问题就不会慌。
最后再分享一个我长期使用的小技巧：每次修改引导配置或者服务单元文件之前，先把当前状态记录下来，包括 grub.cfg 的 hash、initramfs 的文件列表、systemctl list-unit-files 的输出。这样如果改动出了问题，可以快速对照差异，不会因为改得太多而找不到是哪一步捅了娄子。另外，专门准备一个可以启动到 Live 环境的 U 盘，等于给自己留了一条绝对的退路，系统真的起不来时，它就是你的救生圈。
