standard_init_linux.go:178：exec 用户进程导致“exec 格式错误”

问题描述：

docker 开始抛出这个错误：

standard_init_linux.go:178：exec 用户进程导致“exec 格式错误”

每当我使用 CMD 或 ENTRYPOINT 运行特定的 docker 容器时，除了删除 CMD 或 ENTRYPOINT 之外，不考虑对文件的任何更改。这是我一直在使用的 docker 文件，它在大约一小时前一直运行良好：

FROM buildpack-deps:jessie

ENV PATH /usr/local/bin:$PATH

ENV LANG C.UTF-8

RUN apt-get update && apt-get install -y --no-install-recommends \n        tcl \n        tk \n    && rm -rf /var/lib/apt/lists/*

ENV GPG_KEY 0D96DF4D4110E5C43FBFB17F2D347EA6AA65421D
ENV PYTHON_VERSION 3.6.0

ENV PYTHON_PIP_VERSION 9.0.1

RUN set -ex \n    && buildDeps=' \n        tcl-dev \n        tk-dev \n    ' \n    && apt-get update && apt-get install -y $buildDeps --no-install-recommends && rm -rf /var/lib/apt/lists/* \n    \n    && wget -O python.tar.xz "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz" \n    && wget -O python.tar.xz.asc "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz.asc" \n    && export GNUPGHOME="$(mktemp -d)" \n    && gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEY" \n    && gpg --batch --verify python.tar.xz.asc python.tar.xz \n    && rm -r "$GNUPGHOME" python.tar.xz.asc \n    && mkdir -p /usr/src/python \n    && tar -xJC /usr/src/python --strip-components=1 -f python.tar.xz \n    && rm python.tar.xz \n    \n    && cd /usr/src/python \n    && ./configure \n        --enable-loadable-sqlite-extensions \n        --enable-shared \n    && make -j$(nproc) \n    && make install \n    && ldconfig \n    \n    && if [ ! -e /usr/local/bin/pip3 ]; then : \n        && wget -O /tmp/get-pip.py 'https://bootstrap.pypa.io/get-pip.py' \n        && python3 /tmp/get-pip.py "pip==$PYTHON_PIP_VERSION" \n        && rm /tmp/get-pip.py \n    ; fi \n    && pip3 install --no-cache-dir --upgrade --force-reinstall "pip==$PYTHON_PIP_VERSION" \n    && [ "$(pip list |tac|tac| awk -F '[ ()]+' '$1 == "pip" { print $2; exit }')" = "$PYTHON_PIP_VERSION" ] \n    \n    && find /usr/local -depth \n        ( \n            ( -type d -a -name test -o -name tests ) \n            -o \n            ( -type f -a -name '*.pyc' -o -name '*.pyo' ) \n        ) -exec rm -rf '{}' + \n    && apt-get purge -y --auto-remove $buildDeps \n    && rm -rf /usr/src/python ~/.cache

RUN cd /usr/local/bin \n    && { [ -e easy_install ] || ln -s easy_install-* easy_install; } \n    && ln -s idle3 idle \n    && ln -s pydoc3 pydoc \n    && ln -s python3 python \n    && ln -s python3-config python-config

RUN pip install uwsgi

RUN mkdir /config

RUN mkdir /logs

ENV HOME /var/www

WORKDIR /config

ADD conf/requirements.txt /config

RUN pip install -r /config/requirements.txt

ADD conf/wsgi.py /config

ADD conf/wsgi.ini /config

ADD conf/__init__.py /config

ADD start.sh /bin/start.sh

RUN chmod +x /bin/start.sh

EXPOSE 8000

ENTRYPOINT ["start.sh", "uwsgi", "--ini", "wsgi.ini"]

解决方案 1：

我忘了放

#!/bin/bash

在 sh 文件的顶部，问题解决了。

解决方案 2：

如果您尝试在 arm64/aarch64 机器上运行 x86 构建的图像，则可能会发生这种情况。

您需要使用相应的架构重建图像

解决方案 3：

如果在搭载Apple M1 Pro芯片（基于 ARM）的MacBook Pro上构建映像，也可能会出现此错误，因此默认情况下 Docker 构建命令以 为目标。arm64

事实上，Docker 检测到 Apple M1 Pro 平台是linux/arm64/v8

指定构建命令的目标平台，并可选择在版本标签中添加方便的后缀，如下所示：

构建图像

为 ARM64 构建（默认）

docker build -t <image-name>:<version>-arm64 .

针对 ARM64 构建

docker build --platform=linux/arm64 -t <image-name>:<version>-arm64 .

针对 AMD64 构建

docker build --platform=linux/amd64 -t <image-name>:<version>-amd64 .

使用图像

针对 ARM64

FROM --platform=linux/arm64 <image>:<tag>

针对 AMD64

FROM --platform=linux/amd64 <image>:<tag>

环境

芯片：Apple M1 Pro，10 核（8 核性能核 2 核效率核）

Docker 版本 20.10.12，构建 e91ed57

解决方案 4：

添加此代码

#!/usr/bin/env bash

在脚本文件的顶部。

解决方案 5：

如果 Docker 映像是在 M1 芯片上构建的，并上传以供 Fargate 部署，那么您会注意到 Fargate 中的此容器错误：

standard_init_linux.go:228: exec user process caused: exec format error

有几种方法可以解决此问题。您可以：

• 使用以下方式构建你的docker镜像：

docker buildx build --platform=linux/amd64 -t image-name:version .

• 使用以下代码更新 Dockerfile 的 FROM 语句

FROM --platform=linux/amd64 BASE_IMAGE:VERSION

解决方案 6：

遇到同样的错误，我在更改为 AMD 后构建 ARM 映像。问题已修复

该错误通常意味着您尝试在非 amd64 主机（例如 32 位或 ARM）上运行此 amd64 映像。

尝试使用buildx并指定 --platform linux/amd64进行构建

示例命令

docker buildx  build -t ranjithkumarmv/node-12.13.0-awscli . --platform linux/amd64

解决方案 7：

如果您在 AWS ECS 中获得此信息，则您可能使用 Apple M1 Pro 芯片构建了该映像。在您的 Dockerfile 中，您可以添加以下内容：
FROM --platform=linux/amd64 <image>:<tag>。

如果您使用子图像，例如：FROM <parent_image_you_created>:<tag>您需要确保<parent_image_you_created>:<tag>是用构建的FROM --platform=linux/amd64 <image>:<tag>。

解决方案 8：

我目前正在使用 M1 Mac，早些时候我也遇到了这个问题。我实际上意识到，我作为堆栈的一部分部署的 Fargate 任务已经一个多月没有运行了，因为我把它部署在我的 M1 Mac 笔记本电脑上。部署脚本在我旧的基于 Intel 的 Mac 上运行良好。

我刚刚在 CW 日志中注意到的错误（该任务再次失败了一个多月）正是如下情况：

standard_init_linux.go:228: exec user process caused: exec format error

为了修复它，在所有docker build步骤中（因为我有一个用于构建 lambda 层，另一个用于构建 Fargate 任务），我只需更新以添加。请注意，如果我在参数后添加标签，例如像，--platform=linux/amd64它对我来说不起作用。我想知道这是否可能是因为我在脚本的后面引用了标签。-t`img-test:0.1-amd64`:latest

无论如何，这些都是必要的改变。您会注意到，我真正做的只是添加了--platform参数；其他一切都保持不变。

ecr_repository="some/app"

docker build -t ${ecr_repository} \n        --platform=linux/amd64 \n        --build-arg SOME_ARG='value' \n        .

而且我不确定这在技术上是否有必要，但为了安全起见，我还更新了FROM我的Dockerfiles 中的所有语句：

FROM --platform=linux/amd64 ubuntu:<version>

解决方案 9：

另一个可能的原因是文件以 Windows 行尾 (CRLF) 保存。使用 Unix 行尾 (LF) 保存文件即可找到。

解决方案 10：

扩展到可接受的答案：

对于Alpine（无 Bash）图像：

#!/bin/ash

在 sh 文件的顶部，解决了该问题。

解决方案 11：

对于那些尝试在 amd64 Linux 系统上为 aarch64 或 armv7l 架构构建映像并遇到相同错误的人：请检查qemu-user-static软件包是否已安装。如果没有，请sudo apt install qemu-user-static在 Ubuntu/Debian/Mint 等上安装它，或sudo dnf install qemu-user-static在 Fedora 上安装它

解决方案 12：

这些对我都不起作用。为什么没有人提到BOM？

如果文件开头有字节顺序标记，就会出现此错误。

您可以使用以下方式检查：

head -n 1 yourscript | LC_ALL=C od -tc

在 Notepad++ 中，您可以通过在编码菜单中选择适当的选项以不带 BOM 的 UTF-8 格式保存文本：

编码 > UTF-8

解决方案 13：

我在 RHEL 7.3、docker 17.05-ce 中运行离线加载的映像时遇到了同样的问题。RHEL/CentOS 的默认存储驱动程序似乎从设备映射器更改为覆盖。将驱动程序恢复为设备映射器解决了该问题。

dockerd --storage-driver=devicemapper

或者

/etc/docker/daemon.json
{
  "storage-driver": "devicemapper"
}

解决方案 14：

还有一种可能性是 #!/bin/bash 不在第一行。它前面一定什么都没有（没有空行，什么都没有）。

解决方案 15：

这不是对所提问题的直接回答。虽然我在调用“docker-compose up”来启动我的 nodejs 应用程序时遇到了错误。意识到在我的“Dockerfile”中我有CMD ["./server.js"]。

为了修复它，我将其替换为CMD ["npm","start"]，这样就解决了问题。希望如果有人来到这里解决这个异常，可能会觉得这很有用。

解决方案 16：

standard_init_linux.go:228: exec user process caused: exec format error
对我来说，这是因为我的 go 项目中没有main包。希望它能对某些人有所帮助。

解决方案 17：

如果您已安装 buildx 但仍然遇到此错误，则可能是因为缺少跨平台模拟器。

这些可以像这样安装：

docker run --privileged --rm tonistiigi/binfmt --install all

来源： https: //docs.docker.com/build/building/multi-platform/#building-multi-platform-images

当我尝试linux/arm64通过在具有平台的 Gitlab 运行器上运行的 Gitlab 管道构建图像时发生了这种情况linux/amd64。

解决方案 18：

就我而言，我“耗尽”了我的 ECS 实例并再次“激活”它们，此后错误就消失了。

解决方案 19：

container logs test如果您使用运行容器的 IBR1700 路由器，则在使用命令（其中 test 是容器的名称）后在路由器命令行中可能会出现类似的错误。

要解决此问题，您需要构建应用程序，以便它能够在不同的平台上运行。它使用 linux/arm/v7。

docker run -it --rm --privileged docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64
docker buildx create --name mybuilder
docker buildx use mybuilder
docker buildx build --platform linux/arm/v7 --no-cache -t <username/repository>:<tag> . --push

使用此构建推送到存储库意味着它可以在路由器上运行。

https://github.com/cradlepoint/container-samples

解决方案 20：

对我来说，我的 ECS 集群是 arm64 架构，但我的 docker 镜像显示 amd64 架构。我重建了我的 docker 镜像：https://docs.docker.com/desktop/multi-arch/

解决方案 21：

我遇到了类似的问题standard_init_linux.go:228: exec user process caused: exec format error，但答案没有任何帮助。最后我发现它是旧的docker版本17.09.0-ce，也是Circle CI上的默认版本，因此只需将其更改为最新版本即可解决该问题。