容器里 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.sh2. 修改 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. 普通的“开新进程” vsexec的“原地替换”
在 Linux 中，你运行一个命令，通常会发生两件事：
fork：先克隆出一个全新的子进程，这个子进程有自己的 PID。exec：在子进程里加载新的程序代码，把它变成你想要的程序。
而exec命令的特殊之处在于，它只做第二步，跳过了第一步的fork。
exec不会创建新进程，而是在当前进程的“躯体”里，把“灵魂”（程序代码）直接替换掉。
2. 用表格对比
| 操作 | 进程变化 | PID 是否改变 | 环境变量 |
|---|---|---|---|
直接执行bash | 克隆出新子进程，在其中运行新 bash | ✅ 变了（新 PID） | 子进程继承父进程的环境变量 |
使用execexec 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 官方推荐的最佳实践。