OCI 运行时执行失败：执行失败：（...）$PATH 中找不到可执行文件“：未知

Posted 2023-03-13

【中文标题】OCI 运行时执行失败：执行失败：（...）$PATH 中找不到可执行文件“：未知

【英文标题】：OCI runtime exec failed: exec failed: (...) executable file not found in $PATH": unknown

【发布时间】：2018-06-08 14:58:46

【问题描述】：

我已经通过 libav-tools 对一个安装了 ffmpeg 的应用程序进行了 docker 化。应用程序启动没有问题，但是当 fluent-ffmpeg npm 模块尝试执行 ffmpeg 命令时出现问题，但未找到。当我想检查镜像中设置的ffmpeg和linux发行版的版本时，我使用了sudo docker exec -it c44f29d30753 "lsb_release -a"命令，但它给出了以下错误：OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"lsb_release -a\": executable file not found in $PATH": unknown

然后我意识到，我尝试在图像或容器中运行的所有命令都给我同样的错误。

OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"ffmpeg -a\": executable file not found in $PATH": unknown

这是我的 Dockerfile：

FROM ubuntu:xenial
FROM node
RUN apt-get -y update
RUN apt-get --yes install libav-tools
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY package.json /usr/src/app
RUN npm install
COPY . /usr/src/app
RUN npm run build
ENV NODE_ENV production
EXPOSE 8000
CMD ["npm", "run", "start:prod"]

我很乐意寻求您的帮助。非常感谢！

【问题讨论】：

尝试使用docker run --rm -ti your-image-name sh 进入您的容器并找到您的可执行文件。很可能只是PATH问题（你的可执行文件所在的目录不在容器内root unser的PATH中）

我已经用你推荐的命令进入了容器。问题是当我尝试做apt-get install ffmpeg时，结果是：Package ffmpeg is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'ffmpeg' has no installation candidate。但是我可以在我的 ubuntu 16.04 操作系统中获得相同的包。容器中的操作系统可能有问题吗？

你跑apt-get update了吗？

我确实运行了apt-get -y update && apt-get -y upgrade，当我尝试运行lsb_release -a时，在容器内，这次输​​出是sh: 4: lsb_release: not found，对于ffmpeg：sh: 5: ffmpeg: not found。我运行apt-get install libav-tools 并得到# apt-get install libav-tools Reading package lists... Done Building dependency tree Reading state information... Done libav-tools is already the newest version.。如果我find -name "ffmpeg" 输出为空。

首先你必须找到你的可执行文件的绝对路径（也许使用find）。然后，您有 2 个选项：1）在 docker 的 CMD 中使用可执行文件的完整路径（通常在您调用可执行文件的任何地方）2）将包含二进制文件的目录添加到 PATH 环境变量的末尾，例如如：export PATH=$PATH:/my/bin/folder

【参考方案1】：

去掉你的命令周围的引号。当您引用它时，docker 会尝试将完整的字符串 "lsb_release -a" 作为命令运行，但该命令不存在。相反，您希望运行带有参数 -a 且不带引号的命令 lsb_release。

sudo docker exec -it c44f29d30753 lsb_release -a

注意，容器名称之后的所有内容都是在容器内运行的命令和参数，docker 不会将这些作为 docker 命令的选项处理。

---

对于有此错误的其他人，我建议的调试步骤：

验证参数的顺序。容器名称/id 之后的所有内容都是要运行的命令。所以你不想要docker exec $cid -it /bin/sh，因为它会尝试在$cid 容器中运行命令-it。相反，你想要docker exec -it $cid /bin/sh

查看失败的命令，exec 错误后引号中的所有内容（例如 "exec: \"lsb_release -a\" 中的 lsb_release -a）都是试图运行的二进制文件。确保映像中存在二进制文件。例如。如果您使用的是 alpine 或 busybox，bash 可能不存在，但 /bin/sh 存在。该二进制文件是完整的字符串，例如您将能够运行 ls "/usr/bin/lsb_release -a" 之类的内容，并查看文件名中包含空格和 -a 的文件。

如果您使用带有 Git bash 的 Windows 并看到试图运行该命令的长路径，那是 Git bash 试图对 /path/to/binary 进行一些自动转换，您可以通过加倍第一个斜杠来禁用它，例如//bin/sh.

如果您正在运行的命令是容器中的脚本，请检查该脚本的第一行，其中包含 #!/path/to/interpreter，确保该解释器存在于映像中的该路径中，并且该脚本已保存使用 linux 换行符（lf，而不是 cr+lf，在 linux 中读取时，您不会希望文件中显示 \r，因为这会成为它要执行的命令的一部分）。

如果您在运行的命令中没有二进制文件的完整路径，请检查图像中$PATH 的值，并验证二进制文件是否存在于其中一个目录中。例如。您可以通过docker exec -it $cid /bin/sh 和echo $PATH 和type some_command 验证在您的路径中找到some_command。

如果您的命令不是可执行文件，而是内置的 shell，则需要使用 shell 而不是直接执行它。这可以通过docker exec -it $cid /bin/sh -c "your_shell_builtin" 完成

【参考方案2】：

我遇到了这个问题，结果我需要这样做：

docker run $image_name bash -c "$command"

【参考方案3】：

我在 shell 脚本中有 Windows 行尾。换成 LF dos2unix

【参考方案4】：

你必须像下面这样运行：

docker exec sh -c 'echo "$ENV_NAME"'

【讨论】：

虽然此代码可以解决问题，including an explanation 说明如何以及为什么解决问题将真正有助于提高您的帖子质量，并可能导致更多的赞成票。请记住，您正在为将来的读者回答问题，而不仅仅是现在提出问题的人。请edit您的答案添加解释并说明适用的限制和假设。

【参考方案5】：

在我的情况下，我保存了 docker 映像，而不是将其加载到另一台机器上，而是导入了它，这非常不同，并导致我出现类似于此的错误。

【参考方案6】：

docker exec -it <containerId> sh

【参考方案7】：

这件事发生在我身上。我的问题是当我没有正确挂载 Docker 文件系统时引起的，所以我配置了磁盘映像位置并重新绑定文件共享挂载，现在它可以正常工作了。 作为参考，我在 Windows 中使用 Docker Desktop。

【参考方案8】：

我用这个命令解决了这个问题：

1- 运行容器

# docker run -d <image-name>

2- 列出容器

   # docker ps -a

3- 使用容器ID

# docker exec -it <container-id> /bin/sh

【参考方案9】：

我解决的问题很简单：

运行 docker ps -a 检查容器的命令（我的以 /bin/sh 开头） 运行 docker-compose exec /bin/sh （如果那是你的命令的开始

这是在使用docker compose时解决的

【参考方案10】：

您可以使用另一个 shell 来执行相同的命令：

执行时出现错误：

[jenkins@localhost jenkins_data]$ docker exec -it mysqldb \bin\bash
OCI runtime exec failed: exec failed: container_linux.go:345: starting container process caused "exec: \"binsh\": executable file not found in $PATH": unknown

解决方案： 当我使用以下命令执行它时，使用 bash shell 它可以工作：

[jenkins@localhost jenkins_data]$ docker exec -it mysqldb bash
root@<container-ID>:/#

【讨论】：

我很确定您的问题是您在 \bin\sh 中使用了反斜杠。 Linux 不使用这些，所以它正在剥离它们。请改用 /bin/sh。 “bash”有效，因为没有反斜杠。

【参考方案11】：

@papigee 应该可以在 Windows 10 上正常运行。我正在使用带有 git bash 的集成 VSCode 终端，这对我来说总是有效的。

winpty docker exec -it <container-id> //bin//sh

【参考方案12】：

由于我的一个简单的订购错误，我得到了这个。我打了电话

[WRONG] docker run <image> <arguments> <command>

我应该在什么时候使用

docker run <arguments> <image> <command>

类似问题的相同解决方案：https://***.com/a/50762266/6278

【讨论】：

如果我使用 docker-compose 会出现什么错误？我使用docker-compose -f .\a-docker-compose-file.yml up

运行

@otong 您的评论与我的回答无关。请将其作为新问题发布，并在此处详细说明您的具体问题。

这确实也适用于 docker compose 并为我修复了它。非常感谢

【参考方案13】：

这发生在我的 Windows 上。 这些命令中的任何一个都可以工作

在 Windows CMD 上（不切换到 bash）

docker exec -it <container-id> /bin/sh

在 Windows CMD 上（切换到 bash 后）

docker exec -it <container-id> //bin//sh

或

winpty docker exec -it <container-id> //bin//sh

在 Git Bash 上

winpty docker exec -it <container-id> //bin//sh

注意：您可能需要运行使用 /bin/bash 或 /bin/sh，具体取决于容器中的 shell。

原因记录在 Git 的 ReleaseNotes 文件中，这里有很好的解释 - Bash in Git for Windows: Weirdness...

“原因与试图确保 posix 路径最终正确传递给 git 实用程序有关。因此，Windows 版 Git 包含一个修改后的 MSYS 层，该层会影响命令参数。”

【讨论】：

这样的作品：您可能需要运行使用 /bin/bash 或 /bin/sh

kubectl exec -it <pod_name> /bin/sh 为我工作，谢谢

我在 alpine 基础映像上也遇到了这种错误，因为我是使用 bash 而不是从 shell 执行命令。对于 alpine 基础映像，请使用 shell。

【参考方案14】：

如果@papigee确实解决不了，可能是你没有权限。

我尝试了@papigee 解决方案，但没有 sudo 就无法工作。

我做到了：

sudo docker exec -it <container id or name> /bin/sh

【讨论】：

感谢耶稣。很难找到这个答案。

是的，这行得通，谢谢。我假设/bin/bash 在图像中可用。不是，但 /bin/sh 是，它的效果足以满足我的需要。