SuSE容器中启动systemd并执行后续命令的问题及解决尝试

我来帮你梳理下这个问题的核心和可行的解决办法——你遇到的其实是容器环境下运行systemd的典型痛点：

为什么原命令行不通？ #

systemd的设计逻辑就是要作为系统的PID1进程运行，它需要接管进程组管理、信号处理、系统初始化等核心工作。你用/bin/bash -c "/usr/lib/systemd/systemd && echo 'Hi'"启动时，bash才是PID1，systemd只是它的子进程（PID2），这种情况下systemd会因为无法获取必要的系统控制权，直接抛出"无法从用户空间启动"的错误。

用dumb-init完善你的方案 #

你提到用Yelp的dumb-init已经有部分成功，这个思路完全正确！dumb-init的作用就是帮我们在容器里正确把目标进程（这里就是systemd）提升为PID1，同时处理好进程的生命周期和信号转发。给你补全具体的实现步骤：

1. 确保容器内已安装dumb-init：
   在SuSE容器里执行zypper install dumb-init完成安装（如果镜像里还没有的话）。

2. 调整启动命令，确保systemd成为PID1：
   不要直接用bash嵌套启动，而是让dumb-init作为启动入口，先拉起systemd，等它完全初始化后再执行后续命令：

   dumb-init /usr/lib/systemd/systemd &
   # 等待systemd完成系统初始化，避免后续命令执行时机过早
   until systemctl is-system-running --quiet; do
       sleep 1
   done
   echo "Hi"
   

3. Docker Compose中的配置示例：
   如果用docker-compose管理容器，可以这样写service配置：

   services:
     suse-systemd-demo:
       image: your-suse-base-image
       command: ["/usr/bin/dumb-init", "/bin/bash", "-c", "/usr/lib/systemd/systemd & until systemctl is-system-running --quiet; do sleep 1; done; echo 'Hi'"]
       privileged: true
       volumes:
         - /sys/fs/cgroup:/sys/fs/cgroup:ro
   

   注意：启动运行systemd的容器必须开启privileged权限，并且挂载/sys/fs/cgroup卷，这是systemd正常运行的必要条件。

另一种更贴合systemd逻辑的方案 #

如果你不想依赖dumb-init，也可以直接让systemd作为容器的PID1，然后通过systemd的service来管理后续命令：

1. 在容器内创建一个自定义service文件/etc/systemd/system/post-start-command.service：

   [Unit]
   Description=Execute command after systemd initialization
   After=multi-user.target
   
   [Service]
   Type=oneshot
   ExecStart=/bin/echo "Hi"
   RemainAfterExit=true
   
   [Install]
   WantedBy=multi-user.target
   

2. 启用这个service：

   systemctl enable post-start-command.service
   

3. 容器启动命令直接设为/usr/lib/systemd/systemd，这样systemd作为PID1启动，完成初始化后会自动触发我们定义的service，执行echo命令。

总结 #

不管用哪种方案，核心都是让systemd成为容器的PID1进程——dumb-init是更轻量化的快捷方案，而用systemd自身的service机制则更符合它的运行逻辑，你可以根据自己的需求选择。

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