一、问题背景与核心场景

不少开发者在使用Podman容器时，会有在容器内部运行systemd的需求——比如要复刻宿主机的系统服务管理逻辑、测试依赖systemd的应用打包、或者把容器当成轻量虚拟机来用。但很多人第一次尝试时，都会碰到一个卡脖子的问题：容器里的systemd启动失败，报错信息里会提到“cgroup挂载失败”。这篇内容就把这个问题的来龙去脉、解决办法、注意事项讲透，不管你是刚接触容器的新手，还是有一定经验的开发者，都能跟着操作。

1.1 先搞懂两个基础概念（怕你懵，用大白话讲）

先给两个核心概念做“去专业化”解释，不然后面的操作你可能会云里雾里：

  • Podman：一个开源的容器管理工具，和Docker功能类似，但没有中央守护进程，更轻量，权限控制也更灵活。
  • cgroup：Linux内核的一个功能，用来限制、管理容器/进程的资源（比如CPU、内存、磁盘IO）。你可以把它理解成“给进程套的资源笼子”，没有这个笼子，容器里的进程可能会抢宿主机的资源，或者管理混乱。
  • systemd：Linux系统里的“大管家”，负责启动、管理系统服务（比如网络服务、日志服务），还会管理cgroup——因为它需要知道每个进程属于哪个“笼子”，方便统一管控。

简单说：Podman是你手里的“容器搭建工具”，cgroup是容器的“资源笼子”，systemd是容器里的“大管家”，这个管家需要知道笼子的位置，才能正常工作。

二、问题复现：先踩坑，再找坑

为了让你直观看到问题，我们先完整复现一遍错误场景。所有操作的技术栈统一为：Linux 系统（CentOS 7/8、Ubuntu 20.04+ 均可）、Podman 3.0+ 版本。

2.1 操作步骤（带注释）

首先确保你安装了Podman，然后按下面的步骤操作：

# 步骤1：拉一个带systemd的基础镜像（这里用CentOS 8的官方镜像，里面预装了systemd）
podman pull centos:8

# 步骤2：直接启动容器，不加任何特殊参数（这是新手最容易犯的错）
podman run -it --name test-systemd centos:8 bash

# 步骤3：在容器内部启动systemd，观察报错
systemd

2.2 错误结果分析

执行完systemd后，你会看到类似下面的报错：

systemd[1]: Failed to mount cgroup2 controller: Operation not permitted
systemd[1]: Failed to mount cgroup1 controller: No such file or directory
systemd[1]: Failed to set up mount points: No such file or directory

这个报错的核心原因是：Podman默认启动容器时，没有给容器内部的systemd开放访问宿主机cgroup的权限，也没有把cgroup的挂载点正确映射到容器里——相当于管家找不到笼子的位置，自然没法工作。

三、解决方法：分场景操作，总有适合你的

根据你宿主机的cgroup版本（Linux内核支持的cgroup有v1和v2两种，大部分新系统用v2，旧系统用v1），解决方法分两种，操作前先确认你的宿主机版本。

3.1 先确认宿主机的cgroup版本

先在宿主机执行下面的命令，判断是v1还是v2：

# 检查cgroup版本：如果输出有cgroup2，说明是v2；否则是v1
ls /sys/fs/cgroup

3.2 针对cgroup v2的解决方法（主流场景）

大部分新系统（比如CentOS 8、Ubuntu 20.04+）都是cgroup v2，这时候启动容器需要加两个关键参数：

# 步骤1：先删掉之前测试失败的容器（如果存在）
podman rm -f test-systemd

# 步骤2：重新启动容器，加两个关键参数：
# --privileged：给容器开放所有权限（相当于给管家开了宿主机的大门）
# --cgroupns=host：把宿主机的cgroup命名空间直接映射给容器（相当于把笼子的位置告诉管家）
podman run -it --privileged --cgroupns=host --name test-systemd centos:8 bash

# 步骤3：在容器内部启动systemd，观察是否正常
systemd

验证是否成功

如果启动后没有报错，且能看到类似下面的输出，说明成功了：

systemd[1]: Started Recreate /etc/machine-id for the container.
systemd[1]: Started /run mount helper.
systemd[1]: Started udev Kernel Device Manager.

这时候你还可以在容器内部测试systemd的功能，比如启动一个服务：

# 在容器内部安装并启动sshd服务（测试systemd管理服务的能力）
dnf install -y openssh-server
systemctl start sshd
systemctl status sshd # 能看到服务正常运行

3.3 针对cgroup v1的解决方法（旧系统场景）

如果你的宿主机是cgroup v1（比如CentOS 7），启动容器需要加的参数略有不同：

# 步骤1：删掉之前的测试容器
podman rm -f test-systemd

# 步骤2：启动容器，加--privileged参数，同时手动挂载cgroup的子系统
# 注意：cgroup v1的子系统需要单独挂载，下面的命令是把宿主机的cgroup子系统映射到容器
podman run -it --privileged --name test-systemd \
  -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
  centos:8 bash

# 步骤3：在容器内部启动systemd
systemd

验证方法和v2场景一样，能正常启动且服务管理正常就说明成功。

四、关键参数的深度解析（帮你知其所以然）

刚才的解决方法里用到了两个核心参数，很多人不知道为什么要加，这里给你拆解清楚：

4.1 --privileged：给容器“开绿灯”

Podman默认启动容器时，会限制容器的权限（比如不能访问宿主机的设备、不能修改系统级配置），目的是保证宿主机的安全。但systemd作为容器里的“大管家”，需要访问宿主机的cgroup、管理设备、修改系统配置，所以必须加--privileged参数，给容器开放所有权限。

注意：这个参数会让容器拥有和宿主机几乎一样的权限，所以生产环境使用时要谨慎，如果只是测试场景，完全没问题。

4.2 --cgroupns=host：让容器和宿主机“共享笼子”

cgroupns是cgroup的命名空间，Podman默认会给容器创建一个独立的cgroup命名空间，相当于给容器单独套一个“笼子”，但systemd需要直接访问宿主机的cgroup结构（因为它要管理整个系统的资源），所以加--cgroupns=host参数，让容器和宿主机共享同一个cgroup命名空间，相当于把宿主机的笼子位置直接告诉容器里的systemd。

五、应用场景、优缺点与注意事项

5.1 应用场景

在容器里运行systemd的场景主要有三个：

  1. 测试依赖systemd的应用打包：比如你开发的应用需要由systemd管理启动、重启，在容器里运行systemd可以模拟真实的生产环境，测试打包是否正确。
  2. 轻量虚拟机替代：如果你的服务器资源有限，不想开完整的虚拟机，就可以用带systemd的容器来模拟虚拟机的环境，比如部署需要systemd管理服务的业务。
  3. 复刻宿主机的系统逻辑：比如你需要在容器里复刻宿主机的服务管理逻辑，用来做调试、对比测试。

5.2 技术优缺点

  • 优点：
    1. 模拟真实环境：能复刻宿主机的systemd服务管理逻辑，测试更贴近生产。
    2. 轻量：比虚拟机占用的资源少很多，启动速度快。
    3. 灵活：可以随时启动、停止容器，方便调试。
  • 缺点：
    1. 安全风险：--privileged参数会让容器拥有过高的权限，一旦容器被入侵，宿主机也会面临风险。
    2. 依赖宿主机：容器的cgroup直接依赖宿主机的结构，移植性差（比如从宿主机A迁移到宿主机B，可能因为cgroup版本不同出问题）。
    3. 资源隔离性差：因为共享宿主机的cgroup，容器和宿主机的资源隔离性不如普通容器，可能出现容器抢宿主机资源的情况。

5.3 注意事项

  1. 生产环境谨慎使用：如果你的应用不需要依赖systemd，尽量不要在容器里运行systemd，普通容器的隔离性、安全性更好。
  2. 确认cgroup版本：操作前一定要先确认宿主机的cgroup版本，不然参数加错了还是会报错。
  3. 基础镜像选择：尽量用官方的、预装了systemd的镜像（比如centos:8、ubuntu:20.04），避免自己手动安装systemd时出问题。
  4. 权限控制：如果一定要在生产环境用，尽量不要直接用--privileged参数，可以通过--cap-add参数给容器添加必要的权限（比如--cap-add SYS_ADMIN），但需要你对容器的权限有深入的了解。

六、总结

容器里运行systemd时cgroup挂载失败的核心原因，是Podman默认的容器配置没有给systemd开放访问cgroup的权限和正确的挂载路径。解决方法的核心是：给容器开放足够的权限（--privileged），同时把宿主机的cgroup命名空间或挂载点映射给容器。

操作时一定要先确认宿主机的cgroup版本，再选择对应的参数，测试场景可以放心用，生产场景要谨慎评估安全风险。只要按步骤操作，就能轻松解决这个卡脖子的问题。