WSL2 中 systemd 启动失败问题分析与解决

问题现象

在 WSL2 环境中，用户从 Ubuntu 22.04 升级到 24.04 后，发现 systemd 服务无法正常自动启动。系统日志(dmesg)中显示 /sbin/init 启动超时错误，具体表现为：

1. 系统启动时出现 WSL (2) ERROR: WaitForBootProcess:3342: /sbin/init failed to start within 10000 ms 错误
2. systemd 服务状态显示为 inactive (dead)
3. 虽然可以手动启动服务，但无法实现开机自启

根本原因分析

通过分析系统日志和用户报告，可以确定问题主要由以下几个因素导致：

1. systemd 启动超时：WSL2 默认的 init 进程启动超时时间为 10 秒(10000ms)，而较新版本的 Ubuntu 中 systemd 启动可能需要更长时间

2. 服务依赖问题：特别是 NetworkManager-wait-online.service 等服务可能会显著延长系统启动时间

3. 文件系统检查：某些情况下 /etc/fstab 中的无效条目也会导致启动延迟

解决方案

方案一：延长 init 超时时间

1. 编辑 /etc/wsl.conf 文件（如不存在则创建）
2. 添加以下内容：

   [boot]
   initTimeout=60000
   

3. 保存文件后重启 WSL 实例

注意：部分用户反馈 60000ms 可能过长，可以尝试 20000ms 作为折中方案。

方案二：优化 systemd 服务

1. 分析启动缓慢的服务：

   systemd-analyze blame
   

2. 针对问题服务进行处理，例如禁用 NetworkManager-wait-online.service：

   sudo systemctl disable NetworkManager-wait-online.service
   sudo systemctl mask NetworkManager-wait-online.service
   

方案三：检查文件系统配置

1. 检查 /etc/fstab 文件中的无效条目
2. 启动后执行以下命令查看挂载任务：

   systemctl list-jobs
   

3. 移除或修正无效的挂载配置

技术原理深入

在 WSL2 架构中，Linux 内核由 Windows 虚拟化平台托管运行。systemd 作为初始化系统需要完成大量服务启动工作，包括：

1. 设备管理（通过 udev）
2. 日志系统（journald）
3. 网络服务配置
4. 用户会话管理

这些初始化步骤在传统 Linux 环境中通常有足够时间完成，但在 WSL2 的轻量级虚拟化环境中可能遇到时间约束。特别是当系统升级后，新增的服务或配置变更可能导致启动链变长。

最佳实践建议

1. 定期检查服务状态：使用 systemctl list-units --state=failed 查看失败服务
2. 优化启动服务：仅启用必要的服务，特别是图形界面相关服务在 WSL 中往往不需要
3. 监控启动性能：定期使用 systemd-analyze 系列命令分析启动性能
4. 考虑使用轻量级替代方案：对于简单使用场景，可以考虑不使用 systemd 的 WSL 发行版

总结

WSL2 环境中 systemd 启动失败问题通常源于虚拟化环境与完整 Linux 发行版之间的配置差异。通过适当调整超时设置、优化服务依赖关系，可以显著改善系统启动可靠性。理解 WSL2 的特殊性并针对性地进行配置调整，是确保系统稳定运行的关键。

对于系统管理员和开发者而言，掌握这些调优技巧不仅能够解决当前问题，还能为后续的 WSL 环境维护打下良好基础。