Linux系统启动流程：Init进程与systemd启动排障实战

在机房里对着一台起不来的服务器盯屏幕，最磨人的往往不是硬件报错，而是内核日志刷完最后一行之后，画面就停在那儿不动了。那一刻你其实已经越过了内核的边界，进入了用户态的第一棒——Init 进程。这些年排查过的启动问题里，十有八九最后都落在 Init 进程这一环：要么是它没被正确加载，要么是它加载了但某个依赖卡住了，要么是它成功起来了但某个服务在你不知情的情况下被屏蔽了。Linux系统启动流程之Init进程启动这个题目看着像个教科书章节，实际上它是所有启动排障的分水岭：前面是内核的世界，规则由内核定；后面是用户态的世界，规则由 Init 定。我把这部分拆成两条线来讲，一条是老派 System V init 的脚本时代，一条是现在主流发行版普遍使用的 systemd，两条线都要懂，因为你永远不知道自己会接手一台什么年代的机器。

这篇文章适合谁看？如果你是刚接触 Linux、只会敲几个命令的运维新手，看完能搞清楚“启动卡住”到底该看哪里；如果你已经能改服务配置但说不清 target 和 runlevel 的关系，这篇会帮你把底层逻辑打通；如果你在做嵌入式裁剪或者定制启动流程，后面关于 initramfs 交棒、单元类型选择、超时参数取值的内容，可以直接拿去用。我不打算写成手册式的命令罗列，而是按“它为什么这么设计、我实际怎么验证、踩过哪些坑”的顺序走，中间会给出可以直接抄的配置和脚本，也会把那些文档里不写、只有真机跑过才知道的细节说清楚。

1. Init进程到底是什么：内核交棒的最后一公里

1.1 内核启动的尾巴与用户态的开头

要理解 Init，得先看清它接过手的那个瞬间。内核做完自身初始化之后，走的是start_kernel这条主线，一路完成内存管理、调度器、中断、设备树解析、驱动探测，最后进入rest_init，创建出两个关键的内核线程，其中一个后来演变成 PID 1 的雏形。这个线程在kernel_init里做完最后的收尾动作：释放初始化内存段、挂载根文件系统、尝试打开控制台，然后调用run_init_process去执行用户态的 init 程序。它会按顺序尝试几个路径，常见的是/sbin/init、/etc/init、/bin/init、/bin/sh，谁先找到就执行谁。你也可以在内核命令行里用init=参数指定一个别的路径，比如init=/bin/bash，这个参数在救砖场景里非常好用，后面会专门讲。

这里有个容易被忽略的点：如果所有路径都找不到，内核会打印一句 "No init found"，然后 panic。也就是说，Init 进程启动失败，在内核眼里等价于系统启动失败，没有任何补救余地。这跟后面某个服务起不来完全是两个量级的事，前者是致命的，后者只是功能缺失。很多人排查时把两者混为一谈，结果在内核日志里翻半天，其实问题早就跑到用户态的某一个单元文件里去了。

再往下拆一层，从内核到 Init 之间通常还夹着一个initramfs（初始化内存文件系统）。它的作用是提供一个临时的用户态环境，用来加载真正根文件系统需要的驱动，比如磁盘控制器、软 RAID、加密卷、LVM 之类的模块。initramfs 里自己也有一个/init脚本，它跑完必要动作后会调用switch_root把根切到真正的根分区，然后再去执行真正的/sbin/init。所以完整链条是：内核 → initramfs 的 /init → switch_root → 真根文件系统的 /sbin/init。这就解释了为什么有的机器启动时你会看到两次“加载中”的观感，前一次是 initramfs，后一次才是真正的 Init 接管。

1.2 PID 1 的特殊地位：不只是“第一个进程”

Init 拿到 PID 1 这个编号，绝不只是排名第一那么简单，它身上挂着几项别的东西替代不了的内核职责。第一项是孤儿进程的收养：任何一个进程的父进程先退出了，这个进程会被重新挂到 PID 1 名下，由它负责回收。这就意味着如果 Init 自己不处理SIGCHLD，僵尸进程会一直堆着。systemd 在这块做得比较彻底，它借助 cgroup 追踪每个服务的所有后代进程，服务停掉时能连锅端，不会像早期脚本那样只杀主进程、留下一堆残留的子进程在后台跑着。

第二项是信号语义的特殊性。PID 1 对信号的默认处理和其他进程不一样，内核不会替它做那些默认的终止动作，它必须自己显式注册处理函数，否则收到的信号会被直接丢弃。结果就是，你用kill -9 1去杀 Init 通常没有任何效果——这不是系统有保护机制拦住了你，而是 Init 压根没给这个信号注册处理逻辑。这个设计有它的道理：如果 Init 能被随便杀掉，整个系统就没人管进程回收和关机流程了。真要让系统停下来，正确姿势是systemctl poweroff或者老派的init 0，走的是正常的关机路径。

第三项是职责边界。从设计上看，Init 只做三件事：把系统带到可用状态（挂载文件系统、启动必要的服务）、管理服务生命周期、在关机时按逆序收摊。它不该去干业务逻辑，也不该长期占用 CPU。我在一些定制设备上见过把采集程序直接写进 init 脚本里做成前台阻塞的，结果整个启动流程卡在那一步，后面的服务全起不来。这类问题只要理解了“Init 是调度者不是执行者”这一条，就不会犯。

2. 从 System V init 到 systemd：启动管理器选型背后的逻辑

2.1 System V init：脚本时代的 runlevel 模型

老派 System V init 的思路非常直白：一切皆脚本，按编号顺序串行执行。核心配置在/etc/inittab里，最关键的一行是id:3:initdefault:，冒号中间那个数字就是默认运行级别。运行级别的定义大致是：0 关机、1 单用户、2 多用户无网络、3 多用户带网络（命令行）、4 保留、5 带图形界面、6 重启，另外还有个S或s表示单用户维护模式。init 读到initdefault后进入对应级别，然后去/etc/rc.d/rc3.d/（不同发行版路径略有差异）这个目录里，按文件名排序执行里面以S开头的脚本，K开头的脚本则用于切换级别时先停止对应服务。

这套机制的好处是一目了然，你把S10network、S20sshd这类脚本按顺序摆好，启动顺序就是确定的，调试的时候插一行echo就能看到执行到哪一步。缺点是纯串行，一个脚本里 sleep 三十秒，后面所有服务都得跟着等，机器配置再好也白搭。再加上服务之间的依赖关系全靠脚本编号的先后顺序隐式表达，编号一旦撞车或者顺序被后来的软件包打乱，就会出现“网络还没起来 sshd 就启动了”这种经典故障。脚本内部还得自己处理加锁、去重、后台化、PID 文件写入，写得不严谨就会有重复启动和僵尸进程的问题。

我在维护一台十多年前的老机器时，遇到过S99local里被人塞了一段死循环的情况，表现就是启动到最后一个阶段卡死，但因为前面的服务都起来了，看起来“好像已经启动完了”，远程能连但登不进去。最后是靠单用户模式进去注释掉那段脚本才恢复的。这类问题在 systemd 时代也不是没有，只是表现形式变了。

2.2 Upstart 与 systemd：事件驱动和依赖图

Upstart 是为解决 SysV 的串行瓶颈做的一次尝试，核心思路是事件驱动：服务不是按编号跑，而是等某个事件发生（比如网卡 up、某个服务 started）后再被触发。它在一段时间内被某些发行版采用过，但因为生态和工具链的原因，最终没有成为主流。

systemd 走的是另一条路，可以理解为“依赖图 + 并行启动”。每个服务被抽象成一个单元（unit），单元之间用Requires、Wants、After、Before这类关系描述依赖和顺序，systemd 在启动时先把整张图算出来，能并行的全部并行走，有先后关系的才排队。为了让并行成为可能，它引入了好几套激活机制：socket 激活是先把监听套接字建好，服务真来了连接再拉起来；D-Bus 激活是等有人调这个服务的方法时才启动；还有基于路径的 path 单元，文件一变动就触发。这些机制把“必须提前启动”的服务的数量压到了很低。

在 systemd 里，runlevel 被 target 取代了，但为了兼容，老命令init 3、telinit 5依然能用，内部会映射到对应的 target。对照关系基本是这样的：runlevel 0 对应poweroff.target，1 对应rescue.target，3 对应multi-user.target，5 对应graphical.target，6 对应reboot.target。我个人的习惯是尽量用 target 名字思考，因为你在systemctl get-default里看到的就是 target，改默认启动模式也是systemctl set-default，跟 runlevel 数字较劲没有意义。

2.3 两种模型的对照与选型判断

把两套模型放在一起对比，能更清楚地看出各自适用的场景。

选型上没什么可纠结的：新装机器一律 systemd，别为了“熟悉”去退回旧方案；老设备或者资源极其受限的嵌入式环境，如果 systemd 的体积和依赖扛不住，用 BusyBox 自带的精简 init 加一套自写脚本反而是更务实的选择。我在一个内存只有几十兆的采集设备上试过塞 systemd，光启动时的常驻开销就吃掉了可观的余量，换成 BusyBox init 之后整机负载明显下降。所以选型这事要看约束条件，不是越新越好。

3. 核心细节解析：Init 启动阶段的关键机制

3.1 配置文件与默认级别是怎么被读取的

老派 init 的一切从/etc/inittab开始。除了initdefault那一行，里面还有几类常见条目：sysinit指定系统初始化脚本（通常指向rc.sysinit），wait表示等这个脚本跑完再继续，respawn表示进程挂了自动重启（早期的 tty 登录就是靠这个），ctrlaltdel定义三键组合的动作。读懂这个文件，你就知道这台机器在启动时会按什么顺序做哪些事。

需要注意rc.sysinit这个环节，它干的是脏活累活：挂载/proc、/sys、/dev，设置主机名，检查并修复文件系统（fsck），挂载本地和网络文件系统，启用 swap，加载内核模块。这一段出问题是最要命的，比如根分区损坏导致 fsck 交互式卡住，屏幕会停在那儿等输入，看起来像死机，实际上是等你按 Y。我在一台断电后重启的机器上就遇到过，远程根本没法操作，只能到现场接显示器。

systemd 这边没有 inittab 这个概念，默认启动目标记录在/etc/systemd/system/default.target这个软链接上，指向哪个 target 文件就以哪个为目标。想看当前设置直接systemctl get-default，输出通常就是graphical.target或者multi-user.target。要改就systemctl set-default multi-user.target，它会重建这个软链接，不需要手动碰 ln 命令。

3.2 target、依赖关系与启动顺序的真实规则

target 本身不是“运行级别”的等价物，它只是单元的一种，特点是自身不做实际工作，只负责把一批别的单元聚合在一起。multi-user.target里通过Requires和Wants拉起来一堆基础服务：日志、dbus、网络管理、定时任务等等。

这里必须把两个概念分开：Wants和After管的是完全不同的事。Wants表达“我希望它也被启动”，是启动集合的扩张；After表达“它得比我晚启动”，是顺序约束。只写After不写Wants，对方不会被你拉起来；只写Wants不写After，两个服务会并行启动，谁先谁后随机。这是新手最容易写错的地方，我见过不少单元文件里Requires=network.target配After=network.target写反或者只写一半，结果服务时好时坏，重启十次有三次失败，查起来极其难受。

另外还有个细节：Requires是强依赖，被依赖的单元起不来，依赖方也不会启动；Wants是弱依赖，对方失败了不影响自己。network.target和network-online.target的区别也值得说一句，前者只表示网络子系统初始化完成，不保证网卡拿到地址；后者才是“网络真的可用了”。需要联网的服务应该等后者，但要在单元里加Wants=network-online.target和After=network-online.target，同时确认对应的等待服务是启用的，否则network-online.target会立刻“完成”而没有任何实际等待。

3.3 单元文件的骨架与几个必填项的取舍

一个典型的服务单元长这样：

[Unit] Description=Data Collector Service Documentation=man:collector(8) After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/local/bin/collector --config /etc/collector.conf ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5 TimeoutStartSec=30 User=collector Group=collector LimitNOFILE=65535 [Install] WantedBy=multi-user.target

Type这一项的选择逻辑值得展开。simple表示ExecStart启动的进程就是主进程，systemd 立刻认为服务启动完成；forking适用于那种自己 daemonize 到后台的老程序，systemd 会等父进程退出、PID 文件写好才认为启动成功；oneshot用于跑完就退出的任务，通常配RemainingAfterExit=yes；notify要求程序主动通过 sd_notify 汇报就绪，是最精确的一种；dbus用于需要占用 D-Bus 名字的服务。选错了会有什么后果？把forking的程序写成simple，systemd 会把父进程当成主进程，父进程一退出它就认为服务挂了，于是不停重启；反过来把前台程序写成forking，它会一直等 PID 文件等到超时，然后判定启动失败。这两种错配我都踩过，现象都是“手动跑没问题，交给 systemd 就不行”。

RestartSec和TimeoutStartSec的取值也不是拍脑袋。RestartSec=5意思是失败后等 5 秒再拉，这个值太小会在依赖外部资源（比如数据库）的场景里疯狂重试刷日志，太大则恢复变慢；一般 3 到 10 秒是合理区间，配合Restart=on-failure和StartLimitBurst（默认 5 次/10 秒）能防止无限循环。TimeoutStartSec=30表示 30 秒还没就绪就当失败处理，这个值要大于你最慢一次冷启动的实测耗时，我通常会给实测值的 2 倍左右留余量，因为磁盘繁忙时启动耗时波动很大。

[Install]段里的WantedBy决定了systemctl enable时把软链接建到哪个 target 的 wants 目录下。这里有个常见误解：enable只是建立软链接，不启动服务；start只是启动服务，不建立软链接，重启后就没了。要两者都做，用systemctl enable --now xxx。

4. 实操过程：一步步盯住 Init 启动的每个环节

4.1 从内核日志里找到交棒的那一刻

排查启动问题的第一步永远是拿到内核日志。dmesg能看当前缓冲区的输出，journalctl -k -b能看本次启动的内核消息，加-b -1看上一次启动的，这个参数在“机器已经起来了但我想复盘上次为什么挂”时特别有用。

要定位 Init 接手的位置，重点看这几类行：Run /init as init process表示内核要执行 initramfs 里的初始化脚本了；Run /sbin/init as init process表示 switches 到真正的 init 了；再往后出现systemd[1]: Detected architecture、systemd[1]: Set hostname to ...这类以systemd[1]为前缀的日志，说明 PID 1 已经跑起来在干活了。如果后面什么都没有，画面停住，那问题就在 init 启动本身；如果 systemd 的日志一路刷到某个单元之后戛然而止，问题就在那个单元。

我常用的一个组合是这样：

# 看本次启动的内核与早期用户态日志 journalctl -b -k --no-pager | tail -50 # 只看 PID 1 的输出，剥掉噪音 journalctl -b _PID=1 --no-pager # 直接看内核环形缓冲区里的 init 相关行 dmesg | grep -iE "init|switch_root|systemd"

_PID=1这个过滤条件非常好用，它把 PID 1 自己的日志单独拎出来，排除了大量无关的内核和业务日志，一眼就能看到 systemd 在哪个环节停住了。

4.2 用 systemd-analyze 把启动耗时摊开看

机器能正常起来但启动慢，这时候用systemd-analyze系列工具效率最高。

# 总体耗时：内核、initramfs、用户态各占多少 systemd-analyze # 按耗时倒序排列各单元 systemd-analyze blame # 关键链条，看哪条路径拖了后腿 systemd-analyze critical-chain # 生成 SVG 时间线图，适合贴到报告里 systemd-analyze plot > boot.svg

blame的输出有时会给人误导，因为它列出的是每个单元自身的耗时，并行启动的单元耗时是会重叠的。真正要优化的是critical-chain显示的那条最长路径，路径之外的单元再慢也不影响总时长。我见过有人盯着blame里排第一的服务折腾半天，结果一看critical-chain，那条链路上根本没它。

另外补一句，systemd-analyze给出的数字本身有个前提：它统计的是从内核开始到default.target达成的这段时间，如果你的服务是延迟启动或者在 target 达成之后才被拉起来的，它的耗时不会体现在这里。

4.3 挂一个自定义服务上去并验证完整生命周期

光看不如动手。下面这套流程我几乎每台新机器都会走一遍，用来验证自己的理解没问题。

第一步，写单元文件到/etc/systemd/system/下（注意不要直接改/usr/lib/systemd/system/里的文件，那是软件包的地盘，升级会被覆盖）。

[Unit] Description=Dummy Startup Probe After=local-fs.target [Service] Type=oneshot ExecStart=/bin/sh -c 'echo "probe start at $(date +%s)" >> /var/log/probe.log' RemainingAfterExit=yes TimeoutStartSec=10 [Install] WantedBy=multi-user.target

第二步，重载配置并启用。systemctl daemon-reload是必须的，改了单元文件不重载，systemd 用的还是旧内容，这个坑我踩过不止一次，表现为“明明改了配置怎么没生效”。

systemctl daemon-reload systemctl enable --now startup-probe.service systemctl status startup-probe.service cat /var/log/probe.log

第三步，验证重启后是否自动执行。reboot之后再用journalctl -b _PID=1 | grep -i probe确认它被拉起过。这一步是区分“我手动 start 成功了”和“它真的在启动流程里被拉起来了”的唯一办法。

第四步，验证失败处理。故意把ExecStart指向一个不存在的路径，看看Restart和TimeoutStartSec的表现是否符合预期，顺便观察systemctl status里错误码和退出状态的呈现方式。这套演练做完，你对服务生命周期的理解会扎实很多。

4.4 救急场景：单用户、急救模式与绕过 Init

真遇到 Init 起不来，得会用几种降级通道。

用init=/bin/bash进去之后一定要记得根分区通常是只读挂载的，要改东西得先mount -o remount,rw /。而且这种方式进去没有 systemd 管着，没有日志服务，没有进程回收，改动完要重启只能exec /sbin/init或者用echo b > /proc/sysrq-trigger强制重启。我第一次用这个方式的时候改完文件直接reboot，发现命令不存在，愣了半天才反应过来环境里根本没有完整用户态。

rd.break用来断在 initramfs 阶段，进去之后根是挂到/sysroot上的，改密码或者修 fstab 都是在这个路径下操作，操作完exit会继续往下走。这两种通道的区别很关键：一个是停在内核交棒之后、真根挂载之前，一个是停在真根挂载之后、systemd 完成初始化之前。搞清楚自己停在哪一层，才知道该改哪个文件。

5. 常见问题与排查技巧实录

5.1 启动卡住不动：先分清卡在哪一层

屏幕静止是最模糊的症状，处理方法是有层次的。第一步看有没有光标闪烁或者键盘响应，按一下 Caps Lock 看指示灯有没有变化，能变说明内核没死，是某个前台进程在等输入（最常见就是 fsck 交互）。第二步切到别的 tty，如果Ctrl+Alt+F2能出登录提示，说明系统其实起来了，只是图形界面或者某个前台服务卡住了。第三步看日志，能上就别在现场耗。

我在一台机器上遇到过关机之后再开就停在黑屏，日志显示 systemd 一路跑到Reached target Multi-User System之后就没了，缺了后面的Started Update UTMP about System Runlevel Changes。这说明用户态已经基本就绪，卡在了某个后期单元。最后定位是一个自研的服务在ExecStart里做了阻塞式读取，等一个永远不来的串口数据，而它的单元写的是Type=simple且没设超时，systemd 就一直等着。这类问题的特征是日志停在很靠后的位置，看着“快好了”，其实永远不会好。

5.2 服务起不来：按四层顺序往下切

服务启动失败的排查，我习惯按四层走，每层都有明确的判断依据。

第一层是单元语法和加载。systemctl cat xxx看内容、systemctl show xxx看最终生效的属性，如果systemctl status提示 "not found"，检查文件路径和文件名后缀，单元文件名必须和[Unit]里的引用一致。改过文件没生效的，八成是漏了daemon-reload。

第二层是依赖和顺序。systemctl list-dependencies xxx看依赖树，systemctl status里如果显示 "Condition failed" 或者 "Dependency failed"，就顺着依赖往上找。常见的是依赖了一个没启用的 target，或者After引用了不存在的单元名。

第三层是执行环境。手动在 shell 里跑ExecStart那条命令能成功，交给 systemd 就失败，往往是环境差异：PATH 不同、工作目录不同、用户权限不同。单元文件里可以显式写Environment=、WorkingDirectory=、User=、Group=来消除差异。我遇到过一个脚本手动跑得好好的，systemd 一拉就报找不到命令，原因是它依赖某个 shell 函数，而 systemd 用/bin/sh执行，那个环境里没有加载对应的 profile。

第四层是资源与权限。看journalctl -u xxx里的报错，Permission denied就往 SELinux/AppArmor 或者文件权限上想，Too many open files就往LimitNOFILE上调，Out of memory就看是不是设了MemoryMax。这一层的错误信息通常比较直白，难的是把它和“服务起不来”这个表象联系起来。

5.3 问题速查表与几个不写在文档里的经验

几条踩坑换来的经验值得单独说。第一，不要在生产机上用systemctl mask随手屏蔽服务来“加快启动”，屏蔽是建了个指向/dev/null的软链接，后面的人重启十次也起不来，还不容易发现原因，用disable就够了。第二，journalctl的持久化要提前开，默认有些发行版只存内存，机器一重启日志全丢，复盘时啥也没有，/var/log/journal目录建好并重启日志服务即可。第三，写单元文件时把Description写清楚，别图省事写个 "test"，半年后你自己都不认识那是什么。第四，涉及网络的服务一律等network-online.target，别图快用network.target，快那零点几秒换来的是随机的启动失败。

还有一个容易被忽略的点：systemd 默认会限制服务的Restart频率，短时间内连续失败达到阈值后就不再尝试，状态里显示 "start request repeated too quickly"。这时候不是服务本身的问题，而是它在快速失败循环里被限流了，先systemctl reset-failed清掉计数，再去解决根因，否则你会一直看到同一个限流提示而误判。

6. 几个可以直接复用的判断习惯

我这些年处理启动问题，慢慢形成了几个固定的动作。看到一台机器启动异常，第一件事不是敲命令，而是先问清楚三件事：能不能进单用户、上次正常是什么时候、中间动过什么。这三个问题的答案能砍掉一大半排查路径。然后固定用journalctl -b -k和journalctl -b _PID=1两条命令切开内核态和用户态，先确定问题在哪一层再往下钻，避免上来就翻源码或者乱改配置。

对于要长期维护的机器，我会提前做两件事：把日志持久化打开，把systemd-analyze critical-chain的输出存一份基线。有了基线，某天启动变慢的时候一对比就知道是哪一段变的，比凭感觉猜准得多。另外在写任何单元文件时，我会刻意把TimeoutStartSec和RestartSec显式写出来，哪怕用的是默认值，因为后来接手的人看到明确数字才敢判断这是有意的设计还是随手抄来的配置。

最后分享一个我经常用来验证理解的小实验：在测试机上把default.target改成rescue.target，重启，看看系统起来之后是什么样、少了哪些东西、日志里少了哪几行，然后再改回来。这个来回做一次，你对 target 聚合语义、对“系统可用”这个模糊概念的具体含义，会有比读十篇文档更直观的认识。启动流程这东西，看多少遍都不如亲手把它弄挂一次再救回来。