standard_init_linux.go:178：执行用户进程导致“执行格式错误”-IT科技

摘要：问题描述：docker 开始抛出这个错误：standard_init_linux.go:178：执行用户进程导致“执行格式错误”每当我使用 CMD 或 ENTRYPOINT 运行特定的 docker 容器时，除了删除 CMD 或 ENTRYPOINT 之外，不考虑对文件进行任何更改。这是我一直在使用的 doc...

问题描述：

docker 开始抛出这个错误：

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

每当我使用 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：

如果在配备基于 ARM 的Apple M1 Pro芯片的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 架构构建镜像并遇到相同的错误：请检查软件包是否已安装。如果没有，请在 Ubuntu/Debian/Mint 等系统上qemu-user-static安装，或在 Fedora 上安装sudo apt install qemu-user-static`sudo dnf install qemu-user-static`

解决方案 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 的默认存储驱动程序似乎从device-mapper更改为 overlay。将驱动程序恢复为 devicemapper 后问题得到了解决。

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`main`对我来说，这是因为我的 Go 项目中
没有包。希望这能帮到大家。

解决方案 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：

如果您使用运行容器的 IBR1700 路由器，则在使用命令container logs test（其中 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 默认的版本也是老版本，所以只要换到最新版本，问题就解决了。