Linux系统启动不存在\_sysinit标准阶段，现代systemd发行版已弃用/etc/rc.d/rc.sysinit；其功能由local-fs.target、cryptsetup.target、systemd-udevd.service等unit按依赖关系并行实现。
Linux 系统启动时没有一个叫 _sysinit 的标准阶段或脚本——这是常见误解，多源于对旧版 SysV init 或某些定制发行版（如早期 CentOS 5/6）中 /etc/rc.d/rc.sysinit 的误传或混淆。现代主流发行版（RHEL 7+、Ubuntu 16.04+、Debian 8+）已全面采用 systemd，_sysinit 不再存在，也不应出现在配置或排错思路中。
为什么找不到 /etc/rc.d/rc.sysinit？
因为该文件只存在于 SysV init 时代（RHEL/CentOS 6 及更早），且它本身不是“系统级初始化函数”，而是一个 shell 脚本，负责挂载文件系统、启动 udev、设置主机名等基础任务。systemd 启动流程中，这些工作由多个 unit 文件并行完成，例如：
-
systemd-remount-fs.service替代了文件系统重挂载逻辑 -
systemd-udev-settle.service（已弃用）和systemd-udevd.service处理设备节点 -
systemd-sysusers.service和systemd-tmpfiles-setup.service初始化系统用户与临时路径
如果你在 RHEL 8、AlmaLinux 9 或 Ubuntu 22.04 上执行 ls /etc/rc.d/rc.sysinit，会得到 “No such file or directory” —— 这是正常的，不是环境损坏。
systemd 中哪些 unit 实际承担了传统 sysinit 职责？
查看启动依赖链最直接的方式是运行：
systemctl list-dependencies --before sysinit.target
但注意：sysinit.target 在 systemd 中只是一个**同步锚点**（ordering target），不运行任何代码，仅用于保证基础服务（如 local-fs.target、swap.target、cryptsetup.target）在它之前启动。真正干活的是它的前序 targets 和 services：
-
local-fs.target：要求所有本地文件系统（非网络、非 swap）已挂载完毕 -
cryptsetup.target：确保 LUKS 加密卷已解密并可用 -
systemd-journald.service：日志守护进程必须尽早启动，否则早期 boot 日志会丢失 -
systemd-udevd.service：设备事件处理核心，影响后续模块加载和硬件识别
这些 service 的启动顺序由 Wants=、After= 和 Conflicts= 控制，而非脚本执行顺序。
排查服务未按预期加载的常见陷阱
很多运维人员以为“服务没起来”是因为没加到 sysinit 阶段，实则问题常出在 unit 依赖定义错误或目标状态不满足：
- 自定义 service 使用
After=network.service，但未声明Wants=network.service→ network 可能根本没启动，导致依赖悬空 - 服务需要访问
/mnt/data，但 unit 中只写了After=local-fs.target，未加RequiresMountsFor=/mnt/data→ 即使 local-fs.target 完成，该路径仍可能未挂载 - 写了一个
sysinit.target.wants/xxx.service符号链接，但 systemd 会忽略该目录 —— 正确做法是通过systemctl enable xxx.service，它会自动链接到对应 target 的 wants 目录（如multi-user.target.wants/） - 使用
Type=oneshot但忘了加RemainAfterExit=yes→ systemd 认为服务“退出即失败”，不会标记为 active
验证实际加载顺序可运行：systemd-analyze plot > boot.svg，用浏览器打开 SVG 查看各 service 的启动时间线与依赖关系。
真正要关注的不是“sysinit 怎么写”，而是每个 service 的 [Unit] 段是否准确表达了它对文件系统、设备、网络、其他服务的实际依赖。依赖写错比脚本漏执行更难排查，因为没有报错，只有行为异常。
