根本原因是容器单进程模型与systemd完整OS设计目标的结构性矛盾：必须启用--privileged或显式添加SYS_ADMIN、IPC_LOCK、SYS_RESOURCE能力，配置--cgroupns=host并挂载/sys/fs/cgroup，精简镜像中无关systemd单元，且入口点设为/sbin/init。
容器内进程无法使用 systemd，本质不是配置没写对，而是运行模型和安全机制存在结构性不匹配：systemd 要当“小系统”，Docker 默认只给“单进程沙盒”。要让它跑起来，得同时补足底层支撑和权限边界，缺一不可。
必须显式开放核心能力与特权
systemd 启动时需操作内核接口（如挂载 cgroup、设置命名空间），默认被 Docker 严格限制：
- 至少添加三个能力：
--cap-add=SYS_ADMIN --cap-add=IPC_LOCK --cap-add=SYS_RESOURCE -
SYS_ADMIN用于 cgroup 挂载和命名空间管理；IPC_LOCK在 cgroup v2 下支持内存锁定；SYS_RESOURCE控制资源配额，避免服务启动失败 - 不建议直接用
--privileged——虽能一步到位，但会开放全部设备节点和 sysctl 接口，生产环境风险高
cgroup 命名空间必须与宿主机对齐
Docker 默认为每个容器创建独立的 cgroup 命名空间，而 systemd 需要看到完整的 /sys/fs/cgroup 层级结构才能初始化控制器：
- 启动时加参数：
--cgroupns=host，让容器共享宿主机 cgroup 命名空间 - 挂载 cgroup 文件系统：
--tmpfs /sys/fs/cgroup:rw,noexec,nosuid,size=10M - 若宿主机是 cgroup v2 + systemd 混合模式（如较新 RHEL/CentOS），还需确认
/sys/fs/cgroup/unified是否已挂载；否则 systemd 会因找不到 unified 层而卡在 early boot
精简 systemd 单元并修正入口点
标准发行版镜像里的 systemd 带大量面向物理机的单元（如 udev、kmod、getty），在容器中既无设备节点又无依赖，反而导致启动阻塞：
- 构建镜像时清理冗余单元：
RUN rm -rf /lib/systemd/system/multi-user.target.wants/* /etc/systemd/system/*.wants/* - 只保留必要项：
systemd-tmpfiles-setup.service、dbus.socket等基础 socket 单元 - 入口点必须是
CMD ["/sbin/init"]或ENTRYPOINT ["/sbin/init"]，不能是 bash 或应用进程——否则 systemd 无法成为 PID 1，整个 init 流程失效
SELinux 上下文需适配容器运行域
在启用 SELinux 的系统（如 RHEL、CentOS、Fedora）上，systemd 进程若以默认上下文启动，可能被拒绝访问 /sys/fs/cgroup 或绑定 socket：
- 启动容器时显式指定类型：
--security-opt label=type:container_runtime_t - 若使用自定义挂载路径（如 bind mount 的 cgroup 目录），需重标上下文：
sudo semanage fcontext -a -t container_file_t "/path/to/mount(/.*)?"，再执行sudo restorecon -Rv /path/to/mount - 验证是否生效：
ls -Z /sys/fs/cgroup应显示system_u:object_r:container_file_t:s0类型
