一、你遇到的问题本质是什么？

你遇到的不是一个 bug，而是三件事叠加：

① Docker 启动机制

② Linux shell 初始化机制

③ Ascend NPU 环境依赖机制

最终表现为：

同一个镜像，不同启动方式 → 环境变量不一致 → Paddle NPU 初始化失败

---

二、Docker 核心机制（必须搞清）

---

2.1 ENTRYPOINT vs CMD（核心）

✔ ENTRYPOINT：容器“主程序”

ENTRYPOINT ["sh", "gunicorn.sh"]

含义：

容器启动 = 永远执行这个程序

---

✔ CMD：默认参数

CMD ["--port=8017"]

或：

docker run image arg1 arg2

👉 会替换 CMD

---

2.2 最终执行规则（非常重要）

最终执行 = ENTRYPOINT + CMD

例如：

ENTRYPOINT ["bash", "-c"]
CMD ["echo hello"]

最终：

bash -c echo hello

---

2.3 docker run 参数不会改 ENTRYPOINT

例如：

docker run image /bin/bash -c "echo 1"

真实行为：

ENTRYPOINT + CMD 拼接

👉 不会“启动第二个 shell”

---

三、docker run 三个关键参数（你问的重点）

---

3.1 -it（交互模式）

docker run -it image

等价于：

-i：保持 STDIN 打开
-t：分配伪终端

---

✔ 作用

• 让你能“像 SSH 一样进入容器”
• 可以交互输入命令
• Ctrl+C / Ctrl+Z 可用

---

❌ 不加 -it

docker run image

特点：

• 直接执行命令
• 没有交互界面
• stdout/stderr 为主

---

3.2 -d（后台运行）

docker run -d image

✔ 作用：

容器在后台运行

---

对比：

模式	行为
-it	前台交互
-d	后台运行

---

⚠️ 重要区别

docker run -it image

你会看到 log

docker run -d image

你看不到 log，需要：

docker logs -f container

---

3.3 --rm（自动删除）

docker run --rm image

---

✔ 作用

容器退出后自动删除

---

行为对比

是否加 --rm	容器状态
有	退出即删除
无	Exited 状态保留

---

⚠️ 工程影响（很关键）

加了 --rm：

报错 → 容器消失 → 无法排查

不加：

报错 → 容器保留 → 可 inspect / logs / exec

---

四、shell 初始化机制（你问题核心）

---

4.1 bash -l（login shell）

bash -lc "cmd"

会加载：

/etc/profile
~/.bash_profile
~/.bashrc

---

✔ 结果：

环境变量完整：

• ASCEND_HOME_PATH
• LD_LIBRARY_PATH
• PATH
• PYTHONPATH

---

4.2 sh（非 login shell）

sh gunicorn.sh

特点：

• 不读 profile
• 不读 bashrc

---

❌ 结果：

环境“裸的”

→ Paddle NPU 初始化失败

---

五、你真实问题链路（关键）

---

✔ 成功路径

docker run --entrypoint /bin/bash -lc

→ login shell
→ profile / bashrc
→ Ascend set_env.sh
→ LD_LIBRARY_PATH 正确
→ Paddle NPU OK

---

❌ 失败路径

ENTRYPOINT sh gunicorn.sh

→ non-login shell
→ 无初始化
→ libmsprofiler.so 找不到
→ Paddle NPU crash

---

六、为什么错误是 libmsprofiler.so？

表面：

cannot open libmsprofiler.so

本质：

👉 LD_LIBRARY_PATH 不完整

缺：

/usr/local/Ascend/ascend-toolkit/latest/lib64

---

七、docker inspect 为什么重要？

你用过：

docker inspect

它能看到：

• ENTRYPOINT
• CMD
• ENV
• WORKDIR

---

关键点

--entrypoint /bin/bash

👉 会覆盖 Dockerfile ENTRYPOINT

---

八、-lc 到底干了什么？

bash -lc "cmd"

等价：

-l = login shell
-c = 执行命令

---

关键副作用：

👉 触发环境初始化链路

---

九、你这个问题的“本质模型”

可以总结成：

---

🧠 模型：

Docker = 执行器
Shell = 环境初始化器
Ascend = 强依赖环境变量系统

---

❗问题本质：

Docker 没问题
Paddle 没问题
Ascend 没问题

👉 是“shell 初始化路径不一致”

---

十、工业级最佳实践（重点）

---

❌ 不推荐（隐式依赖）

• ~/.bashrc
• /etc/profile
• bash -l
• docker -it 才能跑

---

✅ 推荐方案（工程标准）

---

方案1（最稳）

👉 在业务脚本里显式初始化

source /usr/local/Ascend/ascend-toolkit/latest/set_env.sh

---

方案2（Docker标准）

ENTRYPOINT ["sh", "gunicorn.sh"]

---

方案3（生产级）

gunicorn.sh:
  1. 初始化 Ascend env
  2. 设置 LD_LIBRARY_PATH
  3. 启动服务

---

十一、标准启动对比图（博客重点）

---

✔ 推荐流程

docker run
   ↓
gunicorn.sh
   ↓
source set_env.sh
   ↓
启动服务

---

❌ 不稳定流程

docker run
   ↓
bash -l（依赖环境）
   ↓
profile 自动加载
   ↓
偶尔成功 / 偶尔失败

---

十二、一句话终极总结

Docker 只负责执行入口，真正决定环境是否正确的是 shell 初始化方式，而 Ascend NPU 强依赖 profile/basrc 中的环境变量配置，因此 login shell 与 non-login shell 的差异会直接导致运行结果完全不同。