如何在Docker容器中启用systemctl以运行自定义systemd服务

问题根因 #

你当前配置下执行systemctl报错的核心原因是：Docker容器的PID1进程未设置为systemd，即使配置了特权模式、capability、cgroup挂载，systemd从未作为容器的init系统启动，自然无法连接到systemd的管理总线。

基于现有配置的修正启动命令 #

在你原有docker run参数基础上，需要做3处关键调整：

• 将/sys/fs/cgroup的挂载权限从只读（ro）改为可读写（rw）：systemd需要写入cgroup控制组才能完成服务生命周期管理
• 补充systemd运行必需的tmpfs临时目录挂载：/tmp、/run、/run/lock 为systemd运行时的可写临时存储路径，缺失会导致systemd启动失败
• 强制指定容器的PID1启动命令为systemd的init入口，替代容器默认的bash/sh启动进程

修正后的完整可执行命令：

docker run -dt \
  -p 5000:5000 \
  --name AIPython2 \
  --privileged \
  -v /sys/fs/cgroup:/sys/fs/cgroup:rw \
  --cap-add SYS_ADMIN \
  --tmpfs /tmp \
  --tmpfs /run \
  --tmpfs /run/lock \
  last_python_image \
  /sbin/init

容器内配置校验流程 #

容器启动后，依次执行以下操作确认功能正常：

1. 校验systemd已作为PID1运行：
   执行命令ps -p 1 -o comm=，如果输出为systemd，说明init系统加载成功
2. 重载systemd服务配置并启动自定义业务服务：

   # 重载系统单元文件配置
   systemctl daemon-reload
   # 设置服务开机（容器重启）自动启动
   systemctl enable qsinavAI.service
   # 启动自定义业务服务
   systemctl start qsinavAI.service
   

3. 排查自定义服务的常见配置错误：
   • 确认容器内已存在www-data用户，不存在则需先创建，否则服务启动会报权限不足错误
   • 调整/root/AI/目录的访问权限：当前service文件的WorkingDirectory配置在/root路径下，默认/root目录权限为0700，www-data用户无访问权限，需开放对应目录的读取、执行权限，或将WorkingDirectory迁移至非root用户目录

常见踩坑提示 #

• 不要添加--init参数：该参数的作用是让Docker启动轻量tini进程作为PID1回收僵尸进程，并非启动systemd，添加后会导致systemd永远无法获得PID1权限
• 基础镜像需为内置systemd的发行版：如果使用Alpine等默认采用OpenRC init系统的精简镜像，即使配置了启动参数也无法正常运行systemd，需基于Debian、Ubuntu、CentOS等默认预装systemd的基础镜像定制业务环境
• 如遇cgroup挂载报错，需确认宿主机内核版本与容器内systemd版本的兼容性：5.4以上内核的cgroup v2环境需搭配248版本以上的systemd，无需额外调整cgroup挂载参数

内容的提问来源于stack exchange，提问作者ahmad blat