no such file or directory 的真实原因
standard_init_linux.go 报 exec user process caused: no such file or directory：文件明明在却提示不存在。典型原因有三类：脚本是 Windows 换行符导致解释器识别失败、shebang 指向的解释器在镜像里不存在、二进制依赖的动态库不全。
基本信息
| 原因一 | Windows 编辑的脚本带换行符，解释器识别失败 |
|---|---|
| 原因二 | shebang 里的解释器路径在镜像中不存在 |
| 原因三 | 二进制依赖的动态库缺失 |
| 排查手段 | file 命令与十六进制查看确认格式 |
| 根治办法 | 仓库里统一换行符规范 |
典型使用场景
- Windows 上编辑的入口脚本拿到 Linux 容器里执行失败
- 精简基础镜像缺少解释器时定位问题
- 宿主编译的二进制拷进更薄镜像后启动失败
- CI 构建产物跑不起来时区分格式问题与依赖问题
- 制定仓库换行符规范，从源头消除这类问题
排查与修复
排查与修复
file entrypoint.sh # 看是否提示换行符格式异常
dos2unix entrypoint.sh # 转成 Unix 换行后重建
head -1 entrypoint.sh # 确认解释器路径在镜像里存在
docker run --rm --entrypoint sh app/web:1.0 -c 'ldd /app/bin/server 2>/dev/null | grep -i not || true'线索与对应原因
| 线索 | 对应原因 | 处理 |
|---|---|---|
| 格式检查提示换行符异常 | 换行符问题 | 转换换行符后重建 |
| 解释器路径不存在 | shebang 与镜像不匹配 | 改 shebang 或换基础镜像 |
| 动态库缺失 | 镜像里没有依赖库 | 补依赖或改静态编译 |
| 二进制不完整 | 文件传输或构建异常 | 重新导出或重新构建 |
在仓库里加换行符规范配置能从根本上避免脚本被改成 Windows 换行，比每次手工转换更省事。
这个报错与文件真的不存在很难区分，先用 file 与十六进制查看排除格式问题。
宿主上编译的二进制拷进更薄的基础镜像常缺必要的库，换镜像或改静态编译两种方向都可行。
解释器路径要按目标镜像实际存在的情况写：部分精简镜像只有 sh，写 bash 会直接失败。
排查时先在容器里用 sh 手动执行验证，比反复重建镜像快得多。