为何执行bash docker run ubuntu sleep 10000时Bash多次fork？

首先得纠正你一个小误解：Bash执行外部命令（比如docker这种非内置命令）时，必然会先fork子进程，再在子进程里用exec替换成目标进程——这是为了保证父Bash在命令执行完后还能继续运行。而你看到的“多次fork”其实是不同层级的Bash进程，并非同一个Bash连续fork出来的，咱们一步步拆解：

1. 宿主机层面的进程链 #

你执行的命令如果是bash docker run ubuntu sleep 10000，或者更常见的bash -c "docker run ubuntu sleep 10000"，宿主机上会有两条关键的Bash进程线：

• 你的交互式Bash（PID2426，父进程是yakuake）：这是你输入命令的终端Shell。
• 子Bash进程：如果用bash -c的方式启动，父Bash会先fork出一个子Bash，专门负责解析并执行-c后面的命令字符串。这个子Bash在执行docker run时，又会fork自己的子进程，然后把这个子进程替换成docker进程——所以这时候你会看到宿主机上有两个Bash进程（父+子）。

2. 容器内部的Bash进程 #

这是最容易让你误解的部分：当你执行docker run ubuntu sleep 10000时，Docker不会直接启动sleep进程，而是会通过容器默认的Shell（Ubuntu镜像里默认是/bin/sh，而/bin/sh又链接到Bash）来执行sleep 10000。

也就是说，容器内部的进程链是：bash → sleep。而在宿主机的PID命名空间里，这个容器内的Bash会被分配一个独立的宿主机PID，它的父进程是Docker的运行时组件（比如runc或containerd-shim），和你宿主机的Bash没有直接父子关系，但在htop里会被一起显示出来。

3. 为什么看起来像是Bash多次fork？ #

你在htop里看到的多个Bash进程，其实是三个完全不同上下文的进程：

• 宿主机的交互式Bash（PID2426）
• 宿主机的子Bash（执行docker run命令的Shell）
• 容器内部的Bash（负责启动sleep的容器内Shell）

这三个进程看起来像是同一条fork链，但实际上前两个属于宿主机，第三个属于容器的隔离环境，只是它们都是Bash进程，所以让你误以为是同一个Bash连续fork了多次。

补充一句：如果你想让Docker直接启动sleep而不经过Shell，可以用docker run ubuntu --entrypoint sleep -- 10000，这样容器内就不会有额外的Bash进程，宿主机上也只会看到宿主机层面的Bash（如果有的话）和sleep的宿主机PID。

内容的提问来源于stack exchange，提问作者J. Doe