做了多年Linux系统开发和运维，我最怕听到的一句话是：“机器起不来了。”这个词背后可能藏着几十种原因——硬件挂了、内核崩了、磁盘满了、服务依赖写错了，但不管哪一种，最后几乎都会把目光拉回到同一个名字：Init进程。系统启动的链条千头万绪，可内核在完成自己的初始化之后，只会做一个动作：把控制权交给这个进程，然后由它拉起整个用户态世界。很多人学习时把“Init进程与系统启动”当成一章背过的理论，到了排障现场依然对着日志发愣。这篇内容我打算换个讲法：先把从内核到Init的完整链路跑通，再看清PID 1在进程树里的特殊地位，然后拆一拆老牌System V init和现代systemd各自的思路，最后给一套可以亲手复现的最小Init实验，以及一套启动故障的排查路径。适合正在看系统编程、嵌入式Linux或运维相关知识的读者，也适合那些已经把服务跑起来很多年、却始终没搞懂“开机那几秒到底发生了什么”的老手。

1. 开机后那几秒：内核把接力棒交给谁的完整链路

Linux的启动过程远没有想象中那么玄妙。按下电源键后，CPU先从固定地址执行固件代码，完成内存自检、硬件初始化，再根据启动顺序找到一个可引导设备里的boot loader。UEFI/BIOS这一层负责把控制权从硬件过渡到引导程序，引导程序负责读取内核镜像和解压，内核镜像准备好之后，才会进入真正的“Linux世界”。很多资料喜欢把这整段都塞进“系统启动”这一章，但对排障来说，最需要关注的是内核态和用户态交接的那一瞬间。

1.1 从加电到内核自解压：启动器完成的那几棒

常见的引导程序是GRUB这一类工具。它的任务很纯粹：读取磁盘上的内核文件，把内核和可选的initramfs装载进内存，然后跳转到入口点。内核接管之后，要初始化CPU、中断、页表、内存管理、调度器和各类驱动。这个阶段系统里还没有“进程”的概念，一切都是内核态代码在顺序执行。直到内核把基础环境收拾干净，它才会去寻找根文件系统。

根文件系统为什么要单独强调？因为内核本身只认识设备节点和块设备，它需要找到那个以/为起点的目录树，知道里面装了什么工具和服务。传统做法是直接指定一个根设备，比如root=/dev/sda1，内核挂载它之后，在里面找/sbin/init。现代发行版则普遍使用initramfs：内核先把一段最小文件系统放进内存，执行其中的/init程序，再由这个程序加载存储驱动、解密分区、挂载真实根文件系统，最后通过switch_root或pivot_root把根目录切过去。无论走哪条路，最终都会落到一个可执行文件上。

这个交接点是我一直建议初学者死磕的地方。内核不是在启动“服务”，而是在启动“一个进程”。只要这个进程能被exec成功，内核就不管后面的事了。你可以把init理解为一位被委以重任的管家，内核给了他整个用户态的钥匙，具体怎么安排服务启动、怎么维持进程纪律，全看管家自己的本事。

1.2 根文件系统与init参数：内核移交控制权的条件

内核执行init时，用的不是“fork一个子进程再运行”的方式，而是直接以exec的方式把自己变成那个用户态程序。所以init在进程表里的PID天生就是1，它的父进程为0，也就是内核自己。这个过程有几个重要的内核参数，排障时很常用：

• root=：指定根设备；
• init=/bin/sh：让内核直接执行一个shell而不是标准init；
• rdinit=：指定initramfs里的init程序路径；
• systemd.unit=：现代系统上指定启动目标；
• single或s：进入旧式单用户模式。

很多人第一次用init=/bin/sh时，会惊讶地发现自己进了一个近乎“裸奔”的shell。这是完全正常的：标准init没有运行，/proc没挂载，根文件系统很可能是只读，连基本的环境变量都没有。但恰恰是这个看起来一无所有的环境，给了你在启动链路早期做修复的机会。

1.3 PID 1为何“死不得”：内核的最后一层兜底

在Linux里，如果PID 1退出，内核会直接panic。日志里通常能看到Kernel panic - not syncing: Attempted to kill init!或类似的消息。为什么内核这么“绝情”？因为init是用户态进程树的根节点，几乎所有进程的祖先链最终都能追溯到它。一旦它消失，整棵进程树就失去了根，内核不知道应该由谁来接管那些失去父进程的子进程，也不知道由谁来维护那个“最终收尸人”的位置。

内核也提供了一个subreaper机制，允许某些进程充当局部收养者，但那只适合容器、子命名空间这类场景。在完整的主机系统里，PID 1死亡依然意味着系统不可恢复。这个特性也解释了为什么自定义init程序必须写得足够健壮：如果main函数直接返回，或者中间异常退出，接下来你看到的不是“系统关闭”，而是内核panic。

2. PID 1的特殊身份：Init进程到底在忙什么

很多人对init的理解停留在“启动服务”这四个字上，这是不够的。PID 1真正的工作是维护整个用户态进程世界的秩序：谁被创建、谁退出了、谁变成了孤儿、僵尸进程谁来收，这些脏活累活全部归它管。理解这层，才能真正理解为什么init的实现方式会影响系统的稳定性。

2.1 收养孤儿与收割僵尸：进程表第一管理员的日常工作

一个子进程正常退出后，它并不会立刻从进程表里消失，而是保留一个“僵尸”状态，直到父进程调用wait或waitpid读取它的退出状态，这个残骸才被真正清理。如果父进程比子进程先挂，内核就要想办法给这个子进程找个新父亲。它会优先寻找最近的subreaper，找不到就直接把子进程重新挂给PID 1。

于是init就成了所有“无主进程”的最终归宿。系统里那些被daemonize之后父进程退出的后台进程，那些shell启动后又脱离的任务，最后都会被init收养。init必须不停执行类似waitpid(-1, NULL, WNOHANG)的循环，把已经退出但还占着进程表位置的子进程全部收割掉，否则僵尸进程就会像堆积的垃圾一样越攒越多，最终可能导致无法创建新进程。

这个职责听起来简单，但实际很考验实现水平。早期SysV init在脚本环境中处理这些事，系统负载高时可能来不及回收；systemd则把每个服务放进单独的cgroup，并且在内核事件驱动的框架下做回收，收尸效率明显更高。你可以把init想象成一家孤儿院的院长：不但要收留新来的孩子，还得及时把离院人员的档案注销，否则档案室迟早会挤爆。

2.2 运行级别切换与关机：Init不只是启动器

SysV init把系统运行状态划分成从0到6的多个运行级别，0代表关机，1代表单用户维护模式，6代表重启，2到5根据发行版不同代表多用户或者图形界面。init进程负责监听telinit这类命令，收到切换请求后，它会进入对应目录执行停止旧服务、启动新服务的脚本序列。也就是说，运行级别切换并不是内核完成的，而是init进程自己协调的。

关机流程同样在init的掌控下。很多人以为电源键按下去就是直接断电，实际不是。操作系统需要先把所有服务按依赖的逆序停掉，卸载文件系统，然后由init调用reboot(LINUX_REBOOT_CMD_POWER_OFF)这类系统调用告诉内核“可以断电了”。如果init在关机时卡住，你会看到系统停在某个“Stopping/Starting”提示上，拔电源虽然能解决问题，但很可能带来文件系统损坏的风险。

2.3 “Init”是一个角色，不是一个固定程序

内核其实不关心被你放到PID 1位置上的程序叫什么名字。它可以是/sbin/init，可以是systemd，可以是一个Python脚本，甚至可以是你自己花半小时编译出来的一个小C程序。只要内核能exec它，并且它愿意承担起收养孤儿、回收僵尸、维持用户态秩序的责任，它就是合格的Init。

这个认知特别重要，因为它意味着“初始化系统”这件事是可以被替换和定制的。早期发行版用SysV init，后来出现Upstart，再后来systemd大面积接管。它们变化的核心都围绕同一个问题：如何更高效、更安全地管理服务启动和进程生命周期。明白了这一点，后面所有的技术细节都能串起来看。

3. SysV init的世界观：脚本、编号与软链接的艺术

在systemd之前，SysV init统治了Linux世界很多年。现在虽然大部分发行版默认使用systemd，但SysV init的很多设计思路依然残留在各种脚本和容器方案里。如果你去读老系统，或者维护嵌入式设备，一定绕不开它。

3.1 inittab与rc.d：一张纯文本的启动编排表

SysV init的主配置是/etc/inittab，每行格式通常是id:runlevels:action:process。id只是一个标识符，runlevels表示该条目在哪些运行级别生效，action定义触发方式，process就是实际执行的内容。常见action有initdefault（设置默认运行级别）、sysinit（开机最先执行）、wait（init等待命令结束）、respawn（进程退出后自动拉起，常用于getty）。

一个典型的级别切换就藏在类似l3:3:wait:/etc/rc.d/rc 3这样的条目里。意思是：进入运行级别3时，执行一次/etc/rc.d/rc 3，并且init要等它完全执行完。rc脚本随后会读取/etc/rc.d/rc3.d目录，目录里躺着一堆软链接，指向/etc/init.d下面的真实服务脚本。这种间接跳转看着多此一举，实际是整套设计里最聪明的地方。

3.2 S和K编号背后的命名哲学：先依赖后服务的软连接逻辑

rcN.d目录里的软链接名字有严格规律：以S开头表示启动（Start），以K开头表示停止（Kill），后面跟着两位数字和服务名。进入某个运行级别时，rc脚本会把S开头的链接按字典序执行start，把K开头的链接按字典序执行stop。比如S01sysstat会比S05sshd先跑，K25sshd会在K70network之前停止。数字大小决定了执行顺序，也决定了服务之间的基本先后关系。

为什么不直接在文件里写列表？我个人的理解是，软链接方案给了系统管理员极大的灵活性。一个服务脚本可以同时被多个运行级别引用，链接只是“指针”，调整某个级别的启停集合，不需要改服务脚本本体；想改变启动顺序，只需要重命名链接文件。早期的chkconfig、update-rc.d工具，本质就是在维护这些链接。这套设计非常符合Unix“用小工具组合出复杂行为”的传统。

3.3 串行启动的代价：为什么慢有时就是原罪

SysV init的最大问题在于完全串行。每个脚本执行时，init都要等它返回，才能继续下一个。如果某个脚本在等待网络、等待磁盘挂载或者等待守护进程完成初始化，后面所有服务都得陪着等。脚本之间也没有显式依赖关系，只能靠数字编号“人肉”排序。一个团队十年下来，启动序列往往堆满了历史遗留的编号，没人敢轻易动。

这种设计在单机服务数量少的年代完全够用，但现代系统一开机就要拉起来几十个服务，串行启动的时长让人无法接受。而且编号无法表达复杂依赖，比如“数据库必须在Web应用之前启动，但日志服务其实就是把日志文件写进磁盘，理论上可以和数据库并行”。这些约束靠数字很难优雅表达。所以后来的Upstart和systemd，本质上都在解决同一个问题：怎么把启动从“线性的脚本接力”变成“基于依赖关系的并行调度”。

4. systemd的接管：既是Init又不是传统Init

现在绝大多数主流发行版都用systemd作为PID 1。systemd刚出现时争议很大，但不可否认，它把“初始化系统”提升到了完全不同的维度。了解systemd不能只记命令，要看它背后的模型变化。

4.1 从运行级别到target：声明式依赖让排序交给机器

systemd不再以“运行级别”为核心，而是用unit来描述系统里的每一项资源。服务是一个xxx.service，挂载点是一个xxx.mount，设备是一个xxx.device，它们都遵循统一的配置语法。一个典型的服务单元文件会包含三段：[Unit]声明描述信息和依赖关系，[Service]声明具体启动、停止、重启的逻辑，[Install]声明应该被哪些目标启用。

target则取代了运行级别。比如multi-user.target对应传统的运行级别3，graphical.target对应运行级别5。但target不只是“级别”那么简单，它是以依赖关系组织起来的一组unit。sysadmin不需要手工决定“先启动网络再启动数据库”，而是在数据库的unit里写一句After=network-online.target，systemd会根据整张依赖图自动安排启动顺序。这种声明式配置把排序工作从“人肉编号”变成了“机器计算”，也让并行启动成为可能。

4.2 socket激活与并行启动：两个解决真实痛点的关键机制

如果只能选两个systemd特性讲给别人听，我会选socket激活和并行启动。

socket激活的思路是：服务进程不用一开始就常驻内存，systemd可以先监听这个服务需要的网络socket或Unix socket。当有客户端真正连接进来时，systemd再启动服务进程，并把已经监听的socket文件描述符传递给它。这样那些“偶尔才用一次”的服务可以不占内存，也不需要写复杂的启动顺序；第一次访问时自动拉起，对调用方来说没有任何区别。

并行启动则是依赖图的直接收益。假设A服务和B服务之间没有任何依赖关系，systemd会同时启动它们，而不是像SysV那样一个等一个。这听起来简单，实际效果非常显著，开机速度从几十秒压缩到几秒就是这么来的。用餐厅打比方：以前厨房必须按照固定菜单一道菜一道菜地上，现在后厨先分析哪些菜互不依赖，可以同时下锅，整体出餐时间自然短得多。

4.3 兼容老脚本的迁移之路：那些常见的“不工作”场景

systemd没有把SysV脚本一脚踢开，而是通过systemd-sysv-generator自动为/etc/init.d下的老脚本生成对应的service unit。所以老脚本基本还能用，只是启动和控制命令换成了systemctl start/stop/enable。

但迁移过程中有两个高频坑。第一个是老脚本往往采用“fork到后台”的启动方式，进程启动后主进程立刻退出，真正干活的是它fork出去的子进程。systemd默认期望服务进程保持前台运行，遇到这种老脚本需要声明Type=forking，并告诉它PID文件在哪里，否则systemd会认为服务启动失败并立刻清理进程。第二个坑是脚本里的长时间轮询。很多老脚本用while循环等一个条件，等不到就死等，这在systemd里会触发启动超时，日志里能看到Result: timeout。排障时看到这类状态，先想想是不是老脚本的“脾气”和新模型不匹配，再去改unit参数。

5. Init故障排查实战：从现象到根因的完整链路

启动故障是最让人头疼的一类问题，因为可供观察的信息窗口很短。机器从按下电源到出问题的阶段，往往只有几秒钟，普通情况下你根本来不及抓日志。所以启动排障的第一步，永远是尽量让系统多说一点话。

5.1 第一步永远是剥离美化：让启动日志老老实实说话

绝大多数桌面发行版在启动时都会用quiet splash掩盖内核日志，只显示一个Logo。排障第一件事就是把这些装饰去掉。在GRUB菜单按e进入编辑模式，找到内核启动参数那一行，删掉quiet和splash，并追加systemd.log_level=debug，甚至加上console=ttyS0方便通过串口抓取输出。然后直接启动，就能看到系统究竟卡在哪一步。

如果系统能进入登录界面，但某些服务起不来，那就等开机后再看状态。systemctl --failed会列出所有处于failed状态的unit，systemctl status xx.service会显示单个服务的详细状态和最近日志，journalctl -xb则能查看本次启动的完整日志。这三个命令是排查systemd系统最基础的三板斧，遇到启动问题先敲一遍，比盲目重启有用得多。

5.2 救援目标、单用户与紧急目标：三档应急入口怎么选

如果系统已经起不来，就需要通过启动参数进入应急入口。systemd提供两个常用目标，理解它们的差异能帮你少走弯路。

systemd.unit=rescue.target大致相当于传统的单用户模式，系统会挂载根文件系统，启动少量基础服务，但不会拉起全部用户服务。systemd.unit=emergency.target则更激进：只挂载根文件系统（默认只读），基本服务都不启动，得到一个最小的维护shell。SysV时代对应的启动参数是single或s，现代系统依然兼容这类参数。

进入任意一种维护环境后，第一件事通常是mount -o remount,rw /把根文件系统变成可写，否则你会发现所有配置都改不了。接下来挂载/proc、/sys到对应目录，再根据具体问题着手修复。这个顺序不能乱，我见过不少人卡在“明明进入了救援模式，却什么命令都执行不了”的尴尬里，原因就是根文件系统还挂着只读。

5.3 一个模拟的卡死案例复盘：从failed服务挖到依赖根因

为了把排查链路讲清楚，我模拟一个很常见的场景：机器启动后卡在“A start job is running for Wait for Network to be Configured”很久，最后超时失败。日志里能看到Timed out waiting for network-online.target。

按照前面的三板斧，先systemctl --failed，发现一个wait-network.service处于failed状态。接着systemctl status wait-network.service，看到它的脚本内容是一个永无止境的while循环，一直在尝试ping一个不存在的地址。问题根源并不是这个服务本身重要，而是它被写成了一个必须等待网络就绪才能启动的看门脚本，但脚本内部逻辑写死了，导致它永远无法结束，依赖它的服务也只能跟着卡住。

修复思路很清晰：进入emergency.target，把根文件系统remount成可写，然后把那个服务的启动脚本修正，或者直接把它的依赖关系在unit里调整掉；完成后执行systemctl daemon-reload，重启验证。在这个案例里，真正的根因不是“某个进程挂了”，而是“一个服务在等待一个永远不会满足的条件”。这也正是启动排查里最常见的心法：不要只看某个服务失败，要顺着依赖关系问一句，谁在等谁。

6. 自己动手写一个最小Init进程：理解PID 1的底层机制

前面讲了那么多理论，最后我建议你亲手做一个实验：写一个几十行的C程序，把它装进initramfs，让内核直接exec它。当看到自己写的init把/bin/sh拉起来的那一刻，整个启动模型才算真正印在脑子里。

6.1 用waitpid收尸的最小骨架：C代码拆解

最小init不需要解析配置，只需要三个动作：打开console、fork一个用户程序、waitpid回收子进程。下面这段代码就是完整骨架：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> #include <sys/reboot.h> #include <linux/reboot.h> #include <fcntl.h> static void prepare_console(void) { int fd = open("/dev/console", O_RDWR); if (fd >= 0) { dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); if (fd > 2) close(fd); } } int main(void) { prepare_console(); printf("mini-init: starting...\n"); while (1) { pid_t pid = fork(); if (pid < 0) { printf("mini-init: fork failed\n"); sleep(3); continue; } if (pid == 0) { execl("/bin/sh", "sh", NULL); _exit(127); } int status; waitpid(pid, &status, 0); printf("mini-init: shell exited, respawning...\n"); sleep(1); while (waitpid(-1, NULL, WNOHANG) > 0) ; } return 0; }

prepare_console把标准输入、输出、错误都重定向到/dev/console，否则shell出来了也没有可交互的终端。fork出的子进程里执行/bin/sh，父进程用waitpid等它退出。shell一旦退出，init先顺手把其他已经变成孤儿、等待收割的子进程全部清理一遍，然后重启一个新的shell，实现最简单的“进程拉起-回收-再拉起”循环。

你可以故意在循环里去掉waitpid，或者让main直接返回，跑起来之后会看到内核panic，这才算真正体会到“PID 1死不得”是什么意思。

6.2 把自定义Init装进initramfs并用QEMU验证

要让内核执行这个程序，最简单的方式是用initramfs。编译时必须静态链接，因为initramfs里没有动态链接器：

gcc -Wall -static -o init minimal_init.c

接着准备一个最小根文件系统目录，放一个静态编译的busybox用来提供/bin/sh：

mkdir -p rootfs/bin rootfs/dev rootfs/proc rootfs/sys cp init rootfs/init cp /path/to/busybox rootfs/bin/busybox ln -sf busybox rootfs/bin/sh cd rootfs mknod dev/console c 5 1 mknod dev/null c 1 3 find . | cpio -H newc -o | gzip > ../initramfs.cpio.gz

然后用QEMU直接启动：

qemu-system-x86_64 \ -kernel /boot/vmlinuz-xxx \ -initrd initramfs.cpio.gz \ -append "console=ttyS0 rdinit=/init" \ -nographic

其中的rdinit=/init告诉内核，在initramfs里要执行的第一个程序是根目录下的init。如果一切顺利，你会看到屏幕上出现一个#提示符。注意，这个环境里没有systemd、没有systemctl，也没有完整的目录结构，整个文件系统就是cpio包里那点东西。但正是这种极简环境，把所有启动原理都暴露在了你眼前。

6.3 真实Init比你想象的复杂：骨架之外还要补哪些课

上面的实验只有几十行代码，却把PID 1最核心的三个动作体现出来了：打开控制台、拉起用户程序、回收退出进程。真实世界的init，无论SysV还是systemd，都要远比这个复杂。

它要处理大量的信号：SIGTERM、SIGINT以及关机时内核发送的特殊指令；它要解析各种配置文件和unit依赖关系；它要维护服务状态、收集日志；systemd还要管理cgroup、设备节点、socket激活、定时器，甚至把自己的控制接口通过dbus暴露给系统工具。可以说，现代systemd已经是一个“系统管理框架”，而不仅仅是一个启动器。

还有一个延伸场景值得想一想：容器。容器内也有自己的PID 1，通常不是完整init，而是一个被指定为第一个进程的程序。如果这个程序不处理僵尸进程，容器内的进程就可能出现大量僵尸，最终影响容器退出。很多容器镜像内置的tini等轻量工具，本质就是在一个受限环境里复现init的收尸功能。

最后照例分享一点个人经验：我真的花了很多年才把“Init进程与系统启动”这一章理解透，而且不是靠背概念，是靠亲手让一个假init把shell拉起来。那一次在QEMU里看到自己写的init把/bin/sh搞活，整个开机流程才算真正长在脑子里。后来每次遇到启动故障，我都会先问一句：谁在等谁？是服务在等网络，还是脚本在等磁盘，还是init在等一个永不返回的stop。把这个问题问清楚，大部分故障就解决了一半。如果你刚接触这块，建议照着上面的代码折腾几轮，哪怕故意写坏某个地方再修好，也比抱着文档看十遍有用。