容器里 source 了环境变量，为什么没生效？-育师

容器里 source 了环境变量，为什么没生效？

一、问题场景

我在写 ROS 2 项目的 Dockerfile 时，遇到了一个诡异的问题：

镜像构建完全成功，colcon build编译通过。
ls /ros_ws/install/能看到my_pkg目录，结构完整。
进入容器后，ros2 pkg list | grep my_pkg找不到包。
手动执行source /ros_ws/install/setup.bash后，一切正常。

我的 Dockerfile 里明明已经写了环境配置：

RUN echo "source /opt/ros/humble/setup.bash" >> /root/.bashrc && \ echo "source /ros_ws/install/setup.bash" >> /root/.bashrc && \ echo "source /opt/ros/humble/setup.bash" > /etc/profile.d/ros.sh && \ echo "source /ros_ws/install/setup.bash" >> /etc/profile.d/ros.sh CMD ["bash", "-l"]

为什么source没有生效？这篇文章就来把这个问题彻底讲透。

二、错在哪：环境变量不会跨进程传递

1. 关键认知：环境变量的继承规则

Linux 里有一条铁律：

环境变量只能由父进程单向继承给子进程。子进程修改自己的环境变量，父进程完全看不见。

就像遗产继承：父亲可以把钱留给儿子，但儿子赚了钱，没法自动转回父亲的账户。

2.`source`到底做了什么？

source xxx.sh就是在当前进程里逐行执行脚本。执行完后，脚本里定义的所有环境变量，都留在了当前进程里。

3. 那我们的配置方案哪里出错了？

当我们用登录模式启动 Bash（/bin/bash -l，它作为 PID 1）时：

Bash 启动，开始读取/etc/profile。
Bash 会fork 出一个子 Shell去执行/etc/profile.d/ros.sh的内容。
子 Shell 里确实执行了source，ROS 的环境变量设置成功了。
但是，子 Shell 执行完就退出了，它设置的所有变量也随之消失。
你最终面对的是 PID 1 的 Bash，它对子 Shell 里的变量毫不知情。

用图表示就是：

PID 1: /bin/bash -l (你的主Shell，兜里没有ROS变量) │ │ (执行 profile.d/ros.sh 时，fork 出临时子进程) │ ├── 子进程: bash (临时工，source 在这里成功了) │ └── 设置了 AMENT_PREFIX_PATH 等 │ │ (子进程退出，所有成果丢失，无法传回 PID 1) │ ▼ 你面对的 PID 1，依然是空的

这就是真相：source没有失败，它只是在那个一闪而过的子进程里成功了，但它没法把成果“上交”给主进程。

三、为什么 ENV 硬编码也不是好方案？

后来我尝试用 Dockerfile 的ENV指令直接把路径写死：

ENV AMENT_PREFIX_PATH /ros_ws/install/my_pkg:$AMENT_PREFIX_PATH ENV PATH /ros_ws/install/my_pkg/lib/my_pkg:$PATH

这个方案的确能生效，但有两个致命缺陷：

容易出错：路径是手工拼写的，包名、目录结构一变就得跟着改。
不能自动更新：以后加了新包，colcon build会更新setup.bash，但ENV里的值是写死的，不会跟着变。

违背了自动化原则，不够优雅。

四、终极方案：ENTRYPOINT 脚本接管初始化

核心思路很简单：

既然子进程改了变量父进程看不见，那就让source直接由 PID 1 自己来执行，不给子进程“贪墨”的机会。

1. 创建一个入口脚本

在项目目录下创建entrypoint.sh：

#!/bin/bash# 加载 ROS 基础环境source/opt/ros/humble/setup.bash# 加载工作空间环境source/ros_ws/install/setup.bash# 用 exec 执行传入的命令，环境变量完美传递exec"$@"

chmod+x entrypoint.sh

2. 修改 Dockerfile 尾部

# 拷贝入口脚本 COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh # 设置为容器入口 ENTRYPOINT ["/entrypoint.sh"] # 默认启动 bash CMD ["/bin/bash"]

3. 为什么会生效？

容器启动 │ ▼ PID 1: /entrypoint.sh ← 它自己就是老大，没有父进程可以拦路 │ │ source 直接在 PID 1 的体内执行 │ 变量全部稳稳地落在 PID 1 的进程空间里 │ │ exec /bin/bash │ 用 exec 替换自身，PID 1 变成 bash，环境变量原封不动保留 │ ▼ 你进入容器：环境完美就绪

三个关键点：

/entrypoint.sh自己是 PID 1：不需要把成果交给别人，它自己就是最终的主进程。
source直接在 PID 1 体内执行：不存在“子进程白干了”的问题。
exec "$@"的魔法：exec不是“建新进程”，而是“替换当前进程”。进程体从entrypoint.sh变成bash，但进程 PID 和它携带的环境变量完全保留。

五、补充：为什么`exec`之后进程号（PID）不会变？

要彻底理解ENTRYPOINT方案的精妙，就得搞懂exec这个命令的特殊行为。

1. 普通的“开新进程” vs`exec`的“原地替换”

在 Linux 中，你运行一个命令，通常会发生两件事：

fork：先克隆出一个全新的子进程，这个子进程有自己的 PID。
exec：在子进程里加载新的程序代码，把它变成你想要的程序。

而exec命令的特殊之处在于，它只做第二步，跳过了第一步的fork。

exec不会创建新进程，而是在当前进程的“躯体”里，把“灵魂”（程序代码）直接替换掉。

2. 用表格对比

操作	进程变化	PID 是否改变	环境变量
直接执行`bash`	克隆出新子进程，在其中运行新 bash	✅ 变了（新 PID）	子进程继承父进程的环境变量
使用`exec``exec bash`	当前进程的代码被直接替换为 bash	❌ 不变（还是原来的 PID）	完全保留当前进程的所有环境变量

3. 结合`entrypoint.sh`看效果

# entrypoint.sh 的内容source/opt/ros/humble/setup.bash# PID 1 自己装了满兜变量source/ros_ws/install/setup.bashexec/bin/bash# 原地变身为 bash

执行exec /bin/bash前：PID 1 是/bin/bash /entrypoint.sh，兜里装着 ROS 的环境变量。
执行exec /bin/bash后：PID 1 这个进程还在，但它的程序代码已经变成了/bin/bash。就像一个演员在舞台上换了服装，但人还是那个人。

进程号没变，进程的“身体”还在，所以那些已经设置好的环境变量，作为进程的固有属性被完美地保留了下来。

4. 一个生活化比喻

想象 PID 1 是一辆行驶中的出租车：

普通执行：车子靠边停，乘客（旧进程）下车，一辆新车载着新乘客开走。新车牌是新 PID。
exec执行：车子不停，乘客在车内直接换人。车还是那辆车，车牌（PID）没变，车里的东西（环境变量）也还在。

六、最终可用代码

entrypoint.sh

#!/bin/bashset-esource/opt/ros/humble/setup.bashsource/ros_ws/install/setup.bashexec"$@"

Dockerfile 尾部

COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] CMD ["/bin/bash"]

构建与测试

dockerbuild-tmy-ros-dev:1.0.dockerrun-it--rmmy-ros-dev:1.0# 进入后直接可用，无需手动 sourceros2 pkg list|grepmy_pkg ros2 run my_pkg my_node

七、核心收获

环境变量只在父子进程间单向继承，子进程的修改不会回传给父进程。
配置文件加载时的子 Shell 是环境变量丢失的根源，不是脚本写错了，是执行模型的问题。
ENTRYPOINT脚本是最优雅的解决方案：让source由 PID 1 亲自执行，再通过exec无缝传递给最终 Shell。
exec不换车，只换人，环境变量自然不丢。

容器化 ROS 开发环境，推荐全部使用ENTRYPOINT模式，一劳永逸。这也是 Docker 官方推荐的最佳实践。

容器里 source 了环境变量，为什么没生效？