wsl 中 systemd 无法启动的主因是默认未启用，需通过修改 /etc/wsl.conf（推荐）、arch 镜像免配、命令行临时启用、验证 pid 1 进程及排查 .wslconfig 干扰五种方式解决。
如果您在 Windows 11 中使用 WSL 安装了 Linux 发行版，但无法通过 systemctl 管理服务或启动 systemd，很可能是由于 WSL 默认未启用 systemd 引导机制。以下是实现 systemd 正常启动的多种方法：
一、通过编辑 /etc/wsl.conf 启用 systemd
此方法通过配置 WSL 的全局启动行为，使每次启动发行版时自动初始化 systemd 进程，是官方推荐且最稳定的启用方式。
1、以管理员权限启动 WSL 终端（例如 Ubuntu），执行命令：sudo nano /etc/wsl.conf。
2、在文件中输入以下内容（若文件为空）：
[boot]
systemd=true
3、保存并退出 nano 编辑器：按 Ctrl+O → 回车 → Ctrl+X。
4、关闭当前 WSL 实例：在 PowerShell 或 CMD 中运行 wsl --shutdown。
5、重新启动该发行版（例如点击开始菜单中的 Ubuntu 图标），进入后执行 ps -p 1 -o comm=，若输出为 systemd 则表示启用成功。
二、针对 Arch Linux 发行版的免配置启用方式
Arch Linux 官方 WSL 镜像自 WSL 2.4.12 版本起已默认启用 systemd，无需手动修改 wsl.conf，但需确认镜像版本与运行状态是否匹配。
1、在 PowerShell 中运行 wsl --list --verbose，确认 Arch Linux 状态为 Running 且 VERSION ≥ 2。
2、若为 Stopped 状态，执行 wsl -d archlinux 启动实例。
3、启动后直接运行 systemctl list-units --type=service，若命令无报错且返回服务列表，则 systemd 已就绪。
4、如仍提示“Failed to connect to bus”，检查是否因 cgroup v2 未启用导致；运行 cat /proc/1/cgroup，确认输出中包含 0::/（表示 cgroup v2 已挂载）。
三、使用命令行参数临时启用 systemd
此方法不修改配置文件，适用于测试或单次调试场景，通过启动时注入参数强制启用 systemd 初始化流程。
1、在 PowerShell 中执行 wsl -d Ubuntu --system（将 Ubuntu 替换为您的发行版名称）。
2、终端启动后立即运行 systemctl is-system-running，若返回 running 即表示生效。
3、注意：该方式仅对本次会话有效，关闭后再次启动需重复执行该命令。
四、验证 systemd 是否真正接管 PID 1
即使 wsl.conf 已配置且重启完成，仍需确认 systemd 是否实际成为 init 进程，避免被其他 init 替代或降级为 sysvinit 兼容模式。
1、在 WSL 终端中运行 cat /proc/1/comm，预期输出必须为 systemd。
2、若输出为 init 或 bash，说明 systemd 未启动或被覆盖，需检查 /etc/wsl.conf 是否存在语法错误（如多余空格、缺失换行、括号未闭合）。
3、运行 sudo journalctl --no-pager -n 20 查看最近日志，重点查找包含 Failed to mount cgroup2 或 systemd not found 的条目。
五、修复因 .wslconfig 干扰导致的 systemd 失效
Windows 用户主目录下的 .wslconfig 文件可能覆盖 WSL 行为，尤其当其中设置了 memory、processors 或 kernelCommandLine 时，可能间接抑制 systemd 初始化。
1、在 PowerShell 中运行 notepad $env:USERPROFILE\.wslconfig 检查该文件是否存在及内容。
2、若文件中包含 kernelCommandLine = "..." 行，临时注释或删除该行（在行首加 #）。
3、保存文件后执行 wsl --shutdown，再重新启动发行版。
4、重新检查 cat /proc/1/comm 输出是否恢复为 systemd。
