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


RUN cd /usr/local/bin \
&& { [ -e easy_install ] || ln -s easy_install-* easy_install; } \
&& ln -s idle3 idle \
&& ln -s pydoc3 pydoc \
&& ln -s python3 python \
&& 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"]
304526 次浏览

我忘了放

#!/bin/bash

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

另一个可能的原因是文件保存时使用了Windows行结束符(CRLF)。保存它与Unix行结束符(LF),文件将被找到。

我在RHEL 7.3, docker 17.05-ce中运行离线加载映像时也遇到了同样的问题。RHEL/CentOS的默认存储驱动由名为变为overlay。将驱动程序恢复到设备映射器就解决了这个问题。

dockerd --storage-driver=devicemapper

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

延伸到公认的答案:

对于高山(不含bash)映像:

#!/bin/ash

在sh文件的顶部,解决了这个问题。

还有一种可能是#!/bin/bash不在第一行。在它之前一定什么都没有(没有空行,什么都没有)。

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

为了解决这个问题,我用CMD ["npm","start"]替换了它。希望如果有人降落在这里这个例外可能会发现这有用。

添加以下代码

#!/usr/bin/env bash

在脚本文件的顶部。

在我的情况下,我“耗尽”我的ECS实例,并再次“激活”它们,此后错误消失了。

如果您试图在arm64/aarch64机器上运行x86构建的映像,就会发生这种情况。

您需要使用相应的体系结构重新构建映像

如果您使用的是运行容器的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

得到了同样的错误,我正在建立ARM图像后改变到AMD。固定的问题

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

尝试使用buildx并指定——linux / amd64平台来构建

示例命令

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

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

我有类似的问题standard_init_linux.go:228: exec user process caused: exec format error,但没有帮助从答案。最终我发现它是旧的docker版本17.09.0-ce,这也是Circle CI上的默认值,所以在将其更改为最新的一个问题解决了。

如果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

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

如果映像是在基于arm的苹果M1 Pro芯片的MacBook Pro上构建的,也会发生此错误,因此默认情况下Docker构建命令的目标是arm64

Docker实际上将Apple M1 Pro平台检测为linux/arm64/v8

为构建命令和版本标记指定平台就足够了:

# Build for ARM64 (default)
docker build -t <image-name>:<version>-arm64 .


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


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

环境

芯片:苹果M1 Pro, 10核(8个性能和2个效率)
Docker版本20.10.12,build e91ed57

这些对我都没用。为什么没有人提到物料清单?

如果在文件的开头有字节顺序标记,则会发生此错误。

你可以检查一下:

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

在notepad++中,你可以通过在Encoding菜单中选择适当的选项保存文本在UTF-8没有BOM:

编码的在utf - 8

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

如果你正在使用一个子映像,例如:FROM <parent_image_you_created>:<tag>,你会想要确保<parent_image_you_created>:<tag>是用FROM --platform=linux/amd64 <image>:<tag>构建的。

< p > standard_init_linux.go:228: exec user process caused: exec format error 对我来说,这是因为在我的go项目中没有main包。

我目前正在摇晃一台M1 Mac,我也在早些时候遇到了这个问题。我实际上实现了一个Fargate任务,我已经作为堆栈的一部分部署,并没有运行超过一个月,因为我已经在我的M1 Mac笔记本电脑上部署了它。部署脚本在我的旧的基于英特尔的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} \
--platform=linux/amd64 \
--build-arg SOME_ARG='value' \
.

我不确定这是否是技术上需要的,但为了安全起见,我还更新了Dockerfiles中的所有FROM语句:

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

如果您已经安装了buildx,但仍然遇到这个错误,这可能是因为缺少跨平台模拟器。

可以像这样安装:

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

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

当我试图通过运行在Gitlab运行器上的平台linux/amd64上的Gitlab管道构建linux/arm64映像时,发生了这样的事情。