Cannot execute binary file 之原因

最新推荐文章于 2024-11-11 13:02:53 发布
原创 最新推荐文章于 2024-11-11 13:02:53 发布 · 2w 阅读 · 13 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#docker #linux #运维

本文记录了使用Kaniko构建基于Alpine的Docker镜像时遇到的Go程序运行问题及解决过程。通过排查非root用户、编译目标与执行环境差异等因素，最终定位到动态库缺失问题，并给出了两种解决方案。

文章目录

1. 写在最前面

问题：笔者用 kaniko 构建了一个 docker 镜像，基础镜像是基于 Alpine。构建好后，运行编译后的 go 二进制程序。一直提示下面的错误：

# ./example.exe
sh: ./example.exe: not found

在此处明显看到 example.exe 的文件是存在的。怀疑是 sh有问题，笔者又按照了 bash 后继续尝试

# apk add bash
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/community/x86_64/APKINDEX.tar.gz(1/4) Installing ncurses-terminfo-base (6.2_p20210109-r0)
(2/4) Installing ncurses-libs (6.2_p20210109-r0)(3/4) Installing readline (8.1.0-r0)
(4/4) Installing bash (5.1.0-r0)
Executing bash-5.1.0-r0.post-install
Executing busybox-1.32.1-r6.trigger
OK: 8 MiB in 18 packages
# bash
bash-5.1# /bin/bash example.exe
example.exe: example.exe: cannot execute binary file

到此处错误变为了二进制无法执行。百思不得其解的笔者，只能硬着头皮继续排查。

2. 排查方向

2.1 非 root 用户

# whoami
root

注：此选项排除，笔者是以 root 的用户登陆的。若此处为非 root 用户，可以执行 chmod +x program

2.2 编译目标与执行环境不同

bash-5.1# file example.exeexample.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=r403apSf9gVnhAa92Ma3/CtPwwvYC_Td44-00QCD7/LNwlhyvp3IK5oGI_6pca/H9YPNEE1hvs-0EBN4ZA0, not stripped

bash-5.1# uname -a
Linux d015a01bdfbc 4.15.0-158-generic #166-Ubuntu SMP Fri Sep 17 19:37:52 UTC 2021 x86_64 Linux

注：执行 file 和 uname 命令对比发现，程序的编译目标与执行环境相同，排除此选项

2.3 程序需要的动态库或静态库缺失

「排除一切不可能的，剩下的就算再不可能也是真相」

bash-5.1# ldd example.exe
        /lib64/ld-linux-x86-64.so.2 (0x7ff2cb417000)        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7ff2cb417000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7ff2cb417000)
Error relocating example.exe: __vfprintf_chk: symbol not found
Error relocating example.exe: __fprintf_chk: symbol not found
bash-5.1# ls /lib64
ls: /lib64: No such file or directory

注：检查程序的依赖库，发现本地缺少 lib64 的动态依赖。原因是 Alpine 使用的标准库与大多数发行版不同，它使用的是musl libc ，这个库虽然相比 glibc 更小，更简单，更安全，但是与大家常用的标准 glibc 并不兼容。

2.3.1 解决办法

采用维基百科的建议方案是，安装 glic 作为 musl libc 的补充的方案。

注：原文

If you want to run glibc programs in Alpine Linux, there are a few ways of doing so. You could install glibc as additional to musl (you would have to do this manually), or you could do it the easy way and use either Flatpak (the easiest) or a chroot.

Because there are different use cases, this is just a slight overview about what’s possible and what’s intelligent.

安装 build-base gcompat

bash-5.1# apk add build-base gcompat(1/22) Upgrading musl (1.2.2-r0 -> 1.2.2-r1)
(2/22) Installing libgcc (10.2.1_pre1-r3)(3/22) Installing libstdc++ (10.2.1_pre1-r3)
(4/22) Installing binutils (2.35.2-r1)(5/22) Installing libgomp (10.2.1_pre1-r3)
(6/22) Installing libatomic (10.2.1_pre1-r3)(7/22) Installing libgphobos (10.2.1_pre1-r3)
(8/22) Installing gmp (6.2.1-r0)
(9/22) Installing isl22 (0.22-r0)
(10/22) Installing mpfr4 (4.1.0-r0)
(11/22) Installing mpc1 (1.2.0-r0)
(12/22) Installing gcc (10.2.1_pre1-r3)
(13/22) Installing musl-dev (1.2.2-r1)
(14/22) Installing libc-dev (0.7.2-r3)
(15/22) Installing g++ (10.2.1_pre1-r3)
(16/22) Installing make (4.3-r0)
(17/22) Installing fortify-headers (1.1-r0)
(18/22) Installing patch (2.7.6-r7)
(19/22) Installing build-base (0.5-r2)
(20/22) Installing musl-obstack (1.1-r1)
(21/22) Installing libucontext (1.0-r0)
(22/22) Installing gcompat (1.0.0-r1)
Executing busybox-1.32.1-r6.trigger
OK: 198 MiB in 41 packages
bash-5.1# ./example.exe
Long: 0, ip:time="2022-01-17T12:04:04Z" level=info msg="[NewServer] Start to run http server" file="example.go:30"

4. 等等

笔者开发的是 go 语言，默认应该就是静态链接。为什么此处使用了动态链接呢？重新关注下 file 命令的执行。

bash-5.1# file example.exe
example.exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=r403apSf9gVnhAa92Ma3/CtPwwvYC_Td44-00QCD7/LNwlhyvp3IK5oGI_6pca/H9YPNEE1hvs-0EBN4ZA0, not stripped

结论：

go 本身没有依赖 glibc，但是笔者开发的程序有 cgo 的使用，所以有 libc 的使用，而笔者本地的编译器 clang 和编译镜像里的编译器 gcc 对依赖库的处理有所不同。

4.1 真·解决办法

4.1.1 使用 CGO_ENABLED=0

使用 CGO_ENABLED=0 关掉允许动态链接。

4.1.2 更换依赖的基础镜像

Alpine Linux 默认缺少 glibc 的动态库，改为 ubuntu 18.04.x 可解。

5. 碎碎念

至此，上周踩到的一个神奇的问题才算是初步解决了，当然你要是想知道编译器的区别，也还是可以深究的，但是笔者还有开发要搞，就先记录的到这里吧。

  • 如果一个人影响到了你的情绪，你的焦点应该放在控制自己的情绪上，而不是影响你情绪的人身上。只有这样，才能真正的自信起来。
  • 如果觉得身边的一切都太不如意，那就去喜欢的地方，做喜欢的事，买喜欢的东西。
  • 如果偶尔快乐，那就是生活的意义。

6. 参考资料

phantom_111
关注
【报错】 /root/anaconda3/conda.exe: cannot execute binary file: Exec format error
静谧、淡雅
03-25 610
cannot execute binary file: Exec format error
gitlab-runner CI流水线中出现/bin/sh: cannot execute binary file问题
Less is More
06-01 1315
该问题一般是image中user非root用户引起
Linux基础知识学习:安装JDK出现 cannot execute binary file
大山的博客
09-10 2万+
当我遇到这个问题时，我在网上搜相关资料，其中找到一篇如下解决办法：linux系统下遇到cannot execute binary file的问题，一般由以下情况造成：非root用户或者无执行权限 编译环境不同（程序由其他操作环境复制过来） 对于第一种情况，采用增加执行权限即可chmod +x program对于第二种情况，建议将该程序二进制包拷贝过来，重新编译程序。因为我在实际操作过程中发现我将
Linux中执行java命令报错：cannot execute binary file: Exec format error
失足成万古风流人物的专栏
11-28 1万+
cannot execute binary file: Exec format error
【Windows】Windows 平台使用 MinGW 编译程序遇到报错 cannot execute binary file: Exec format error 的一种原因
我是一只小小小小鸟
01-21 4038
exec format error 原因很多，其中一个原因可能是 ELF 文件依赖的某个静态依赖库存在问题。
linux下解决：cannot execute binary file
热门推荐
ken_chiu的专栏
09-09 21万+
linux系统下遇到cannot execute binary file的问题，一般由以下情况造成： 非root用户或者无执行权限编译环境不同（程序由其他操作环境复制过来） 对于第一种情况，采用增加执行权限即可chmod +x program 对于第二种情况，建议将该程序二进制包拷贝过来，重新编译程序。因为我在实际操作过程中发现我将美国的VPS的整个操作系统环境打包后下载到本地服务器上解
cannot execute binary file
qq_39656564的博客
06-01 3786
cannot execute binary file 错误的一种解决思路
-bash: ./imxdownload: cannot execute binary file: Executable file format error（可执行文件格式错误）
qq_37459242的博客
01-02 4059
这可能是因为可执行文件不符合当前主机架构，因此需要在当前主机上再次编译生成可执行文件。 1. 复制 把源代码文件复制到当前主机 2. 编译 sudo gcc imxdownload.c -o imxdownload 3. 尝试 将以上生成的可执行文件复制到 .bin 所在的文件夹。 赋予权限 下载到 SD 卡。 $: sudo chmod 777 imxdownloa $: ./imxdownload u-boot.bin sdb I.MX6ULL bin download softw
Unbuntu ./btest : cannot execute binary file: Exec format error解决方案（CSAPP）
mazamu的博客
06-29 3141
用WSL尝试CSAPP的第一个实验碰到的问题： 用下面的查了一下文件的类型： file btest 然后用各大搜索引擎找到一个类似的问题，原因是unbuntu还不支持32-bit i386 ELF binaries： GitHub上已经有人碰到过这个问题但是似乎还是没有解决，地址： Support for 32-bit i386 ELF binaries 解决方案： vim Makefile 找到里面的： 改为： 我的可以用了。 不知道是否适用于其它地方，你们如果遇到也可以类试地修改一下。
Cannot execute binary file
cuanxixia1496的博客
11-12 1万+
Cannot execute binary file linux系统下遇到cannot execute binary file的问题，一般由以下情况造成： 1. 非root用户或者无执行权限 使用chown命令...
解决报错：cannot execute binary file: Exec format error
m0_74795952的博客
11-11 8646
该错误发生时，通常是在尝试执行一个不兼容的二进制文件。很可能是因为该二进制文件运行在一个不同体系架构的操作系统中，比如 64 位的可执行文件在 32 位 Linux 操作系统运行，就会出现这种情况。
【linux】运行run文件显示cannot execute binary file
我的笔记本
12-01 1万+
linux系统下遇到cannot execute binary file的问题，一般由以下情况造成： 1. 非root用户或者无执行权限 2. 编译环境不同（程序由其他操作环境复制过来）对于第一种情况，采用增加执行权限即可chmod +x program对于第二种情况，建议将该程序二进制包拷贝过来，重新编译程序。 3. 硬件平台与软件不一致 ， 例如： 32位系统，下载了个64位的软件，x86平台上传的却是arm平台。结果就无法执行 如果使用 file 命令检查的结果是 data， 而不是可执行文件，
解决 cannot execute binary file: Exec format error
qq_56992543的博客
07-25 3万+
"cannot execute binary file: Exec format error" 错误通常发生在尝试执行一个不兼容的二进制文件时。这可能是因为你正在尝试运行一个不同体系结构的可执行文件，或者文件本身可能已经损坏。我在qmake修改的时候不小心安装了x86架构的编译器无法编译arm架构的。我这里的解决方法是重新安装如何指定qmake的路径即可。安装完交叉编译器一定要记得使用source 命令去使能。指令格式为：source + 交叉编译器的安装路径。后面就可以愉快的编译+烧录了。
解决 cannot execute binary file
weixin_34342905的博客
12-09 3334
场景说明在执行任何的程序之前，必须确保程序和系统的版本位数是一致的，如果一种是x64,一种是32位的，就会出现上述的问题具体例子[root@jack 迅雷下载]# ./qt-opensource-linux-x64-5.7.0.runbash: ./qt-opensource-linux-x64-5.7.0.run: cannot execute binary fi...
Linux配置JDK环境变量报：-bash: /usr/……java: cannot execute binary file: Exec format error
Order pipul的博客
05-11 6637
-bash: /usr/……java: cannot execute binary file: Exec format error
/bin/bash: cannot execute binary file
耕耘
01-05 6201
容器内部无法执行二进制文件，/bin/bash: cannot execute binary file
gcc ——“cannot execute binary file”
NBA_1的博客
01-03 3413
今天在cygwin下面使用gcc编译的时候，用了命令，而非makefile。 命令如下： gcc -o myapp -c hello.c 结果使用 ./myapp 运行时，提示： “cannot execute binary file” 。 开始我百思不得其解，通过ls查看文件权限，将其mode 改成 0777。 再次执行./myapp，依旧提示 “cannot execute binary file” 。 于是baidu, google， 最终找到了原因： The -c flag tells it no
Error response from daemon: container bdae44e961ff86eed00f0b4efbd752dbc8c759b554b0981fd41a7f8ec623f194 is not running aliee@LAPTOP-7JTO0EPP:~/application-core$ docker logs apollo_neo_dev_10.0.0_pkg /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file /bin/bash: /bin/bash: cannot execute binary file
最新发布
07-13
<think>我们正在解决Docker容器启动失败并出现“/bin/bash无法执行”的问题，特别是在安装Apollo时出现的错误。根据用户描述，错误信息为“Error response from daemon: container ... is not running”以及可能出现的“cannot execute binary file /bin/bash”。这通常与容器启动时执行入口点（entrypoint）失败有关，可能由于架构不匹配、文件损坏或权限问题导致。 ### 逐步解决方案 #### 1. **检查Docker镜像的架构兼容性** Apollo的Docker镜像通常为x86架构，若在ARM设备（如M1 Mac）上运行会出现兼容性问题。使用以下命令检查镜像架构： ```bash docker inspect --format='{{.Architecture}}' apollo:6.0.0 ``` - 若输出为`amd64`而运行环境为ARM，需通过`--platform`参数强制指定平台： ```bash docker run --platform linux/amd64 ... [其他参数] ``` #### 2. **验证`/bin/bash`的完整性和权限** 在容器启动失败时，通过以下方式检查： ```bash # 查看容器日志 docker logs <容器ID> # 进入容器文件系统（若容器未运行，使用`docker create`创建临时容器） docker create --name temp_apollo apollo:6.0.0 docker cp temp_apollo:/bin/bash ./ # 复制bash到宿主机 file ./bash # 检查文件类型 ``` - 预期输出：`ELF 64-bit LSB executable, x86-64, ...` - 若显示`ARM`架构则说明镜像错误。 #### 3. **重新拉取镜像并验证** 删除损坏的镜像并重新拉取： ```bash docker rmi apollo:6.0.0 docker pull apolloauto/apollo:6.0.0 # 确保使用官方镜像 ``` #### 4. **修复启动脚本（关键步骤）** 参考Apollo官方启动脚本[^4]，确保`docker run`命令包含正确的`--entrypoint`参数： ```bash docker run --entrypoint /bin/bash \ --gpus all \ -it \ -e DISPLAY=$DISPLAY \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -v $HOME/.Xauthority:/root/.Xauthority \ ... # 其他挂载参数（见原始问题） ``` **注意**：必须保留`-it`参数以保持交互终端。 #### 5. **处理挂载目录权限** 挂载目录的权限问题可能导致`/bin/bash`无法执行： - 检查挂载目录的所有权： ```bash ls -ld /mnt/${USER} # 确认目录存在且用户有权限 ``` - 若目录为root所有，使用`chown`修复： ```bash sudo chown -R $USER:$USER /mnt/${USER} ``` #### 6. **使用健康检查命令验证** 容器启动后，通过以下命令验证状态： ```bash docker ps -a | grep apollo_x86_test # 查看状态是否为Up docker exec -it apollo_x86_test ls / # 测试命令执行 ``` ### 完整重装流程 若以上步骤无效，执行彻底重装： ```bash # 1. 清理旧容器和镜像 docker rm -f apollo_x86_test docker rmi apollo:6.0.0 # 2. 拉取官方镜像 docker pull apolloauto/apollo:6.0.0 # 3. 使用修正后的启动脚本（见步骤4） ./docker/scripts/dev_start.sh --verbose # 显示详细日志 ./docker/scripts/dev_into.sh ``` > **根本原因**：此错误通常由架构不匹配（如ARM设备运行x86镜像）、镜像损坏或挂载目录权限冲突导致。修正启动参数并确保环境兼容性可解决95%的案例[^1][^4]。 §§相关问题§§ 1. 如何检查Docker容器内二进制文件的架构兼容性？ 2. 在Docker中如何正确处理挂载目录的权限问题？ 3. Apollo的Docker镜像支持哪些硬件架构？ 4. 如何调试Docker容器的启动失败问题？ 5. 在非x86设备上运行Apollo有哪些替代方案？</think>### 解决 Docker 容器启动失败及 `/bin/bash` 无法执行的问题 #### 1. **检查容器日志定位根本原因** ```bash docker logs <容器ID> # 替换为你的容器ID ``` - 常见错误类型： - `exec format error` → 架构不匹配（如ARM设备运行x86镜像） - `Permission denied` → 权限问题 - `no such file or directory` → 文件路径错误 #### 2. **验证镜像架构兼容性**（关键步骤） ```bash # 检查镜像架构 docker inspect apollo:6.0.0 --format='{{.Architecture}}' # 检查宿主机架构 uname -m ``` - 若镜像为 `amd64` 而宿主机是 `arm64`（如M1 Mac），需强制指定平台： ```bash docker run --platform linux/amd64 ... [其他参数] ``` #### 3. **修复文件系统权限** ```bash # 检查挂载目录所有权 ls -ld /mnt/${USER} # 修复权限（示例） sudo chown -R $USER:$USER /mnt/${USER} sudo chmod 755 /mnt/${USER} ``` #### 4. **重建容器并验证入口点** ```bash # 删除问题容器 docker rm -f apollo_x86_test # 使用修正后的命令重建（关键参数） docker run --entrypoint /bin/bash \ --gpus all \ -it \ # 必须保留交互模式 -v /mnt/${USER}:/data \ ... # 其他挂载参数 --name apollo_x86_test \ apollo:6.0.0 \ -c "echo '成功进入容器!'" # 测试命令执行 ``` #### 5. **镜像完整性验证与修复** ```bash # 检查镜像层完整性 docker history apollo:6.0.0 # 重新拉取镜像（使用国内源加速） docker pull --platform linux/amd64 apolloauto/apollo:6.0.0 ``` #### 6. **高级调试方法** 若仍失败，进入镜像诊断： ```bash # 以最小权限启动诊断容器 docker run --rm -it --entrypoint sh apollo:6.0.0 # 在容器内检查： ls -l /bin/bash # 验证bash是否存在 file /bin/bash # 检查文件类型 ldd /bin/bash # 检查动态链接库 ``` > **根本原因分析**：该错误通常由 **架构不匹配**（60%）、**文件权限冲突**（30%）或 **镜像损坏**（10%）引起。优先检查架构兼容性（步骤2）和挂载目录权限（步骤3）可解决90%案例[^1][^4]。 --- ### 验证成功的标准 1. 执行后显示交互式shell提示符：`root@hostname:/apollo# ` 2. 能运行基本命令： ```bash ls / # 查看根目录 cat /etc/os-release # 查看系统信息 ```
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值