企业官网建设流程全解析

Podman--systemd选项完全指南：在容器中无修改运行 systemd 的原理与实战

【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址: https://gitcode.com/gh_mirrors/po/podman

导读

本文以 Podman 的--systemd运行选项为核心，深入讲解如何在无需修改系统镜像的前提下，让 systemd 作为 PID 1 在容器内完整运行（典型场景包括构建类容器镜像、运行 systemd 风格的服务与 Podman 自身的 quadlet 单元）。文章不仅覆盖true/false/always三种取值的行为差异、systemd 模式下自动生效的 tmpfs 挂载、默认停止信号与container_uuid环境变量等全部细节，还结合 Podman 仓库源码（pkg/specgen/generate/container_create.go 与 libpod/container_internal_linux.go）剖析其底层实现与判定逻辑，最后给出 SELinux 环境下的调优命令与可验证的端到端测试用例。读完本文，你将能够准确判断一个容器是否启用了 systemd 模式、理解该模式对容器 OCI 运行时的具体改动，并能在自己的环境中复现与验证。

说明：--systemd选项在podman create与podman run两个命令中同时生效，二者共享同一份选项文档（见 docs/source/markdown/options/systemd.md 开头的说明注释）。

一、选项语法与三种取值语义

--systemd接受如下语法：

--systemd=true | false | always

默认值为true。三种取值的语义如下：

自动判定逻辑的源码实现

true值下的"自动判定"并非黑盒，其实现位于 pkg/specgen/generate/container_create.go#L412-L445。简化后的逻辑如下：

useSystemd := false switch s.Systemd { case "always": useSystemd = true case "false": // 不启用 case "", "true": // 取镜像默认 Cmd 作为命令来源 if len(command) == 0 && imageData != nil { command = imageData.Config.Cmd } if len(command) > 0 { useSystemdCommands := map[string]bool{ "/sbin/init": true, "/usr/sbin/init": true, "/usr/local/sbin/init": true, } // 若命令形如 /bin/sh -c <cmd>，剥去 shell 前缀再判定 if command[0] == "/bin/sh" && command[1] == "-c" { cmd = command[2:] } if useSystemdCommands[cmd[0]] || (filepath.Base(cmd[0]) == "systemd") { useSystemd = true } } default: return nil, fmt.Errorf("invalid value %q systemd option requires 'true, false, always'", s.Systemd) }

几个值得注意的实现细节：

• 镜像 Cmd 兜底：podman create阶段用户未显式指定命令时，会回退到镜像元数据中的Config.Cmd来判定，因此"镜像默认跑 init，用户没传命令"也能正确触发 systemd 模式；
• shell 前缀剥离：当命令以/bin/sh -c开头（例如通过构建步骤或包装脚本启动时），判定前会先剥掉前两个参数，再检查真正的目标命令是否为 systemd，避免误判；
• 大小写不敏感：选项值在写入 SpecGenerator 前会统一做小写归一化与合法性校验。校验位于 pkg/specgen/container_validate.go#L61-L64，非法值（如--systemd=yes）会直接报错：--systemd values must be one of "true, false, always"。这一行为也有对应的端到端测试覆盖，见 test/e2e/systemd_test.go#L130-L145（测试中Always、True、False均被接受）。

二、启用 systemd 模式后 Podman 自动执行的容器改动

当判定结果为"启用 systemd 模式"时，Podman 会在创建容器时自动施加以下改动（这也是原文档中列出的核心清单）：

1. 自动挂载 tmpfs

Podman 会在以下目录挂载 tmpfs 文件系统：

• /run
• /run/lock
• /tmp
• /sys/fs/cgroup/systemd（仅在 cgroup v1 系统上）
• /var/lib/journal

需要说明的是，原文档中的/var/lib/journal与源码实现存在一处差异：在 libpod/container_internal_linux.go#L222-L265 的setupSystemd()函数中，实际被挂载 tmpfs 的目录是/run、/run/lock、/tmp与/var/log/journal（注释也写明 "It also expects to be able to write to /sys/fs/cgroup/systemd and /var/log/journal"）。这是文档与当前仓库代码版本不一致之处，读者在排查挂载情况时以源码行为为准。

这些 tmpfs 挂载的挂载选项为rw、rprivate、nosuid、nodev，并附加tmpcopyup与可选的size=参数。若用户指定的挂载目标已存在（MountExists命中），Podman 会跳过自动 tmpfs，尊重用户显式配置。相关测试 test/e2e/systemd_test.go#L122-L128 验证了 systemd 模式下/run挂载不会带有noexec标志——这正是 systemd 需要可执行文件的原因。

2. 默认停止信号改为 SIGRTMIN+3

启用 systemd 模式后，若用户未显式设置停止信号，Podman 会将容器的停止信号设置为SIGRTMIN+3。对应实现见 pkg/specgen/generate/container_create.go#L446-L455：先通过util.ParseSignal("RTMIN+3")解析出信号值，仅在s.StopSignal == nil（用户未设置）时才会覆盖。systemd 使用 SIGRTMIN+3 作为其有序关停信号，因此该默认值能让podman stop优雅地通知 systemd 关机。

3. 注入container_uuid环境变量

Podman 会在容器环境中注入container_uuid，取值为容器 ID 的前 32 个字符。实现在 libpod/container_internal_linux.go#L225-L234：该函数先扫描容器进程环境，若用户已经自行设置了container_uuid=，则不会重复注入（containerUUIDSet检查）。

4. 特权模式下不挂载虚拟控制台

当配合--privileged运行时，systemd 模式不会挂载虚拟控制台设备（/dev/tty\d+），避免特权容器内出现大量无用的 tty 设备节点。

5. cgroup v2 下可写挂载 /sys/fs/cgroup

在 cgroup v2 系统上，/sys/fs/cgroup会被以可写方式挂载，使 systemd 能够直接管理 cgroup 层次。源码 libpod/container_internal_linux.go#L267-L293 给出了更细的区分：先移除原有的/sys/fs/cgroup挂载，然后——

• 若容器拥有独立的 cgroup 命名空间（hasCgroupNs），以cgroup类型挂载，选项为private, rw；
• 否则以 bind 方式将宿主/sys/fs/cgroup挂载进来，选项为bind, private, rw。

这一整套改动合在一起，目的正如原文档所述：让 systemd 能在受限容器（confined container）中直接运行，无需对镜像做任何修改。

三、底层开关：WithSystemd()与容器配置

上述所有改动的总开关是 libpod 层的WithSystemd()选项，定义于 libpod/options.go#L513-L524：

// WithSystemd turns on systemd mode in the container func WithSystemd() CtrCreateOption { return func(ctr *Container) error { if ctr.valid { return define.ErrCtrFinalized } t := true ctr.config.Systemd = &t return nil } }

它只是把容器配置中的Systemd布尔标志置为true（容器一旦 finalized 便不可再修改）。setupSystemd()以及挂载、信号、环境变量等具体动作，则在容器运行时规格（OCI spec）生成阶段据此标志执行。从源码结构看，--systemd选项在 SpecGenerator 中以字符串形式保存（见 pkg/specgen/specgen.go#L125-L135 的Systemd string字段，注释明确说明它与--sdnotify的行为关联），并在pkg/specgen/generate/container_create.go的创建路径中被消费。

此外，--shm-size-systemd选项可独立控制这些 systemd 专属 tmpfs 挂载的大小（默认64m，传0时限制为宿主可用内存的 50%，详见 docs/source/markdown/options/shm-size-systemd.md），它通过WithShmSizeSystemd()传递到setupSystemd()中生成size=挂载选项（pkg/specgen/generate/container_create.go#L630-L631、libpod/container_internal_linux.go#L237-L240）。克隆已有容器时，ConfigToSpec也会保留该配置（pkg/specgen/generate/container.go#L392-L416）。

四、实战操作示例

示例 1：显式强制 systemd 模式

podman run --name my-sd --systemd=always \ registry.fedoraproject.org/fedora:latest \ /sbin/init

always强制启用，即使镜像 Cmd 不是 systemd 也会触发。适用于镜像 Cmd 未设置 init、但你明确要以 systemd 作为 PID 1 启动的场景。

示例 2：利用默认自动判定

podman create --name auto-sd <镜像>

默认--systemd=true。若镜像的Config.Cmd指向/sbin/init、/usr/sbin/init、/usr/local/sbin/init或systemd，Podman 会自动进入 systemd 模式；普通应用镜像则不受影响，保持原有行为。

示例 3：显式禁用

podman run --rm --systemd=false <镜像> /sbin/init

即使命令是/sbin/init，也会按普通容器启动，不注入container_uuid、不改停止信号、不自动挂载 systemd 相关 tmpfs。

验证容器是否处于 systemd 模式

podman inspect my-sd --format '{{.Config.SystemdMode}}' # 期望输出：true

inspect输出中的Config.SystemdMode字段正是WithSystemd()设置的内部标志，端到端测试也以此字段断言，见 test/e2e/systemd_test.go#L108-L120。

五、SELinux 环境下的必要调整

systemd 在启动时会尝试向 cgroup 文件系统写入数据。在启用 SELinux 的系统中，容器默认被禁止写入 cgroup 文件系统，因此即使开启了 systemd 模式，systemd 仍可能因权限问题启动失败。此时需要在宿主上开启container_manage_cgroup布尔值：

setsebool -P container_manage_cgroup true

-P使设置持久化，重启后依然生效。该步骤只影响 SELinux 分离（enforcing）系统；在不启用 SELinux 的环境中可以跳过。原文档特别强调这一前置条件，是"systemd 在受限容器中无修改运行"目标能否落地的关键一环。

六、适用场景与边界说明

• 适用场景：构建/运行以 systemd 为 init 的镜像（如 RHEL/Fedora/CentOS 系列基础镜像中的 systemd 服务容器）、需要 systemd 单元语义的容器、以及配合 Podman quadlet（/usr/lib/systemd/system下的.container单元，见 cmd/quadlet）由 systemd 宿主托管容器时的标准配置；
• 作用对象：仅作用于单容器运行模式，--systemd选项本身不会改变镜像文件，也不修改宿主的 systemd；
• 信号交互：启用后默认停止信号变为 SIGRTMIN+3，意味着podman stop会先向容器内的 systemd 发送有序关停信号，而不是直接 SIGTERM/SIGKILL；若你自定义了--stop-signal，则保持你的设置不变；
• 版本前提：本文所描述行为与判定逻辑以当前仓库代码为准（--systemd文档见 docs/source/markdown/options/systemd.md，实现见 pkg/specgen/generate/container_create.go 与 libpod/container_internal_linux.go），不同版本间行为可能略有差异，升级后建议通过podman inspect复核。

七、小结

--systemd是 Podman 面向"容器内运行完整 init 系统"这一诉求提供的开关：true（默认）根据容器命令自动判定，false彻底关闭，always无条件启用。启用后 Podman 自动完成 tmpfs 挂载、SIGRTMIN+3 默认停止信号、container_uuid注入、特权容器跳过虚拟控制台以及 cgroup v2 可写挂载等一系列适配，使 systemd 无需修改镜像即可在受限容器中工作；在 SELinux enforcing 系统上还需配合setsebool -P container_manage_cgroup true。从源码视角看，这一能力由 pkg/specgen/generate/container_create.go 的判定与libpod.WithSystemd()（libpod/options.go）的开关协同完成，并得到 test/e2e/systemd_test.go 中多组端到端用例的验证，读者可以据此在自己的 Podman 环境中放心复现。

【免费下载链接】podmanPodman: A tool for managing OCI containers and pods.项目地址: https://gitcode.com/gh_mirrors/po/podman