![./executable: 无法执行二进制文件](https://linux22.com/image/42140/.%2Fexecutable%3A%20%E6%97%A0%E6%B3%95%E6%89%A7%E8%A1%8C%E4%BA%8C%E8%BF%9B%E5%88%B6%E6%96%87%E4%BB%B6.png)
我有一个脚本,当我通过 ssh 连接到服务器并自行执行它时,该脚本运行良好,但在以下情况下会出现问题:哈德逊,一个持续集成服务器,运行它。
我正在嵌入式 Linux 系统(目标)上进行自动化测试。目标通过串行连接到服务器 A (RHEL 5),并通过 minicom 进行操作。服务器 B (FC 12) 构建在目标上实际运行的测试,并且可以 ssh 到服务器 A。服务器 C (RH) 托管 Hudson,服务器 B 作为从属服务器。
我编写了一个 runscript (http://linux.die.net/man/1/runscript) 脚本来完成实际目标所需的一切;它启动映像,从服务器 B 挂载目录并执行测试。服务器 B 上的 bash 脚本使用 runscript 脚本以及一些伴随操作来调用 minicom。我在服务器 B 上有一个 bash 脚本,它使用
ssh -t -t ServerA bashScript.sh
让这些测试在目标上运行。我在服务器 C 上,我可以通过 ssh 到服务器 B 并执行 ssh 到服务器 A 的脚本来运行这些测试,该脚本使用 runscript 执行 minicom。呼。 回顾:
服务器 A:Hudson 使用其从属机制 ssh 到服务器 B。
服务器B:kickOffTests.sh
有线路ssh -t -t ServerA runTests.sh
服务器 A:runTests.sh
调用一个 perl 脚本,该脚本调用minicom -S my.script ttyE1
启动后的目标:从测试所在的服务器 B 挂载一个目录,并进入该目录。它调用另一个 bash 脚本来运行测试,这些测试是编译后的 C 可执行文件。
现在,当我我自己执行这些脚本中的任何一个,它们都会做它们应该做的事情。然而,当 Hudson 尝试做同样的事情时,在 minicom 会话中,它抱怨“又一个 bash 脚本”中的一行调用了 C 可执行文件,./executable
,./executable: cannot execute binary file
关于linux我还有很多东西要学,但我推测这个问题是由于Hudson没有与控制台连接造成的。我不知道哈德逊到底做了什么来控制它的奴隶。我尝试export TERM=console
在运行 kickOffTests.sh 之前在配置中使用该行,但问题仍然存在。
谁能向我解释发生了什么事以及我该如何解决它?我无法从这个等式中删除任何服务器。也许可以将 minicom 排除在外,但这会为本项目增加未知的时间,因此我更喜欢使用我已有的解决方案。
答案1
该消息cannot execute binary file
与终端无关(我想知道是什么让你这么认为——我建议避免在问题中做出这样的假设,因为它们往往会将你的实际问题淹没在混乱的红鲱鱼中)。事实上,它是 bash 的表达方式ENOEXEC
(更常见的表达为exec format error
.
首先,确保您没有意外尝试将此可执行文件作为脚本运行。如果您编写了,这会告诉 bash在与调用脚本相同的环境中. ./executable
执行(而不是在单独的进程中)。./executable
如果文件不是脚本,则无法完成此操作。
否则,此消息意味着该./executable
格式不是内核可识别的格式。但我对正在发生的事情没有任何明确的猜测。如果您可以通过以不同的方式调用该脚本在同一台计算机上运行该脚本,那么它就不仅仅是一个损坏的文件或错误体系结构的文件(可能是这样,但还有更多)。我想知道目标启动的方式是否可能有所不同(可能是竞争条件)。
以下是可能有帮助的其他数据列表:
file …/executable
服务器 B 上的输出。- 有关目标的一些信息,例如
uname -a
if it's unix-like 的输出。 - 检查目标是否每次都看到相同的文件内容:在 Yet-another-bash-script 调用之前运行
cksum ./executable
或md5sum ./executable
或您在目标上拥有的任何方法./executable
。检查 Hudson 调用、成功的手动调用和服务器 B 上的结果是否相同。 - 添加到
set -x
另一个 bash 脚本的顶部(就在该#!/bin/bash
行下方)。这将产生脚本所做的一切的跟踪。比较痕迹并报告任何差异或异常情况。 - 描述当您手动运行脚本以及涉及 Hudson 时目标如何启动。可能是目标的启动方式不同,并且某些提供格式支持的可加载模块
./executable
在 Hudson 调用中未加载(或尚未加载)。您可能希望set -x
在其他脚本中使用来帮助您,并检查目标的启动日志。
答案2
如果您缺少脚本顶部的 shebang 行,则可能会发生这种情况。确保脚本以以下内容开头:
#!/bin/bash
这仅在我运行脚本时才出现sudo -u <user>