RHEL 8.6上Podman 4.1.1间歇性OCI runtime错误求助

环境信息 #

$ podman version
Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.17.7
Built:        Wed Oct 12 08:42:59 2022
OS/Arch:      linux/amd64

runc版本：

runc version 1.1.3
spec: 1.0.2-dev
go: go1.17.12
libseccomp: 2.5.2

核心配置：overlay存储驱动（开启metacopy=on）、XFS文件系统、rootless模式关闭、SELinux启用。

问题现象 #

执行容器启动脚本时间歇性触发报错：

$ ./start.sh
Error: OCI runtime error: runc: runc create failed: unable to start container process: waiting for init preliminary setup: read init-p: connection reset by peer

约每8次启动尝试中有1次能成功进入容器。

排查思路与解决方案 #

1. 验证runc与Podman兼容性 #

Podman 4.1.1与runc 1.1.3存在已知的间歇性启动兼容性问题，可尝试：

• 升级runc至1.1.4及以上版本（通过RHEL官方源或编译安装）
• 若升级受限，临时降级runc至1.1.2版本测试是否解决问题

2. 调整存储驱动配置 #

metacopy=on模式在高并发场景下易引发资源竞争，可调整配置：

• 编辑/etc/containers/storage.conf，将overlay.mountopt修改为nodev（移除metacopy=on）
• 重启podman服务：systemctl restart podman
• 清理存储缓存：podman system prune -af后重新测试

3. 排查SELinux干扰 #

SELinux启用状态下可能间歇性阻止容器init进程操作：

• 临时切换SELinux至Permissive模式：setenforce 0，测试启动成功率
• 若问题消失，查看audit日志定位具体拒绝操作：ausearch -m avc -ts recent
• 添加自定义SELinux策略，或启动容器时指定SELinux标签：podman run --security-opt label=type:container_runtime_t ...

4. 清理残留容器与存储缓存 #

当前存在120个停止状态的容器，残留存储文件可能导致冲突：

• 执行全量清理：podman system prune -af（删除未使用的容器、镜像、卷）
• 停止所有podman进程后，手动清理存储目录：rm -rf /docker/storage/*，再重新初始化存储

5. 开启调试日志定位细节 #

通过日志获取更精准的报错信息：

• 启动容器时添加调试参数：podman run --log-level debug ...
• 实时查看podman服务日志：journalctl -u podman.service -f
• 监控runc相关日志：journalctl -t runc -f，关注init进程通信环节的异常

6. 检查启动脚本的资源竞争 #

排查start.sh是否存在资源抢占问题：

• 若脚本同时启动多个容器，添加sleep 1类延迟避免并发冲突
• 确认脚本中无重复绑定端口、挂载相同卷的操作，保证每个容器实例资源唯一

内容的提问来源于stack exchange，提问作者808mrb