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

Posted

技术标签:

【中文标题】standard_init_linux.go:178: exec 用户进程导致“exec 格式错误”【英文标题】:standard_init_linux.go:178: exec user process caused "exec format error" 【发布时间】:2017-07-18 14:29:18 【问题描述】:

docker 开始抛出这个错误:

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

【问题讨论】:

【参考方案1】:

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

【讨论】:

【参考方案2】:

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

【讨论】:

【参考方案3】:

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

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

使用 buildx 并指定 --platfom linux/amd64

尝试构建

示例命令

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

【讨论】:

【参考方案4】:

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

【讨论】:

【参考方案5】:

添加此代码

   #!/usr/bin/env bash

在脚本文件的顶部。

【讨论】:

@akki 入口点必须是可执行的。如果初始 shell 文件不是,则会导致错误。 很好,你拯救了我的一天 @jjmerelo 我不同意:在文件不可执行的情况下——你会得到一个不同的错误,说“权限不足”。【参考方案6】:

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

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

【讨论】:

谢谢!我最近将我的 docker 东西移到了树莓派上的 Kubernetes——忘记了不同的架构——不得不更改我的所有图像以使用 arm32v7 或 arm64v8。你为我指明了正确的方向! 如何重建具有不同架构的映像? @JasonSwett - 在 docker 中检查多架构构建:docker.com/blog/multi-arch-build-and-images-the-simple-way 随着 ARM 在开发机器上越来越流行,人们尝试将映像部署到 x86_64 实例,这将是非常有用的信息!谢谢。 如果有人在 x86 机器上运行镜像时遇到这个问题,请使用--platform linux/amd64 构建 docker 镜像。【参考方案7】:

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

【讨论】:

【参考方案8】:

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

为了解决问题,我将其替换为 CMD ["npm","start"] 并解决了问题。希望如果有人因这个例外而登陆这里可能会发现这很有用。

【讨论】:

【参考方案9】:

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

【讨论】:

【参考方案10】:

扩展到接受的答案:

对于 alpine(没有 bash)图像:

#!/bin/ash

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

【讨论】:

【参考方案11】:

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

dockerd --storage-driver=devicemapper

/etc/docker/daemon.json

  "storage-driver": "devicemapper"

【讨论】:

这对我来说是唯一可行的解​​决方案。我更喜欢配置解​​决方案,因为另一个会产生一个新的活动进程,并且可能只会暂时修复它。【参考方案12】:

另一个可能的原因可能是文件以 Windows 行结尾 (CRLF) 保存。用 Unix 换行符 (LF) 保存它,文件就会被找到。

【讨论】:

【参考方案13】:

忘记放了

#!/bin/bash

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

【讨论】:

谢谢!经过一个小时的拉扯,并检查了 10 次架构(arm/x64 等)是否匹配,您的答案挽救了一天! p.s.:对于像我这样创建 linux docker 的 windows 用户,不要忘记从文件中删除 windows 换行符(\r),否则错误会不断出现! 我在使用这个解决方案后得到了它的工作,之前我遇到了同样的问题。 我的“#!/bin/bash”前面有一个空格 我以某种方式删除了入口点开头的#。真是浪费时间。 这甚至不是特定于 Docker 的,这只会在从 .NET Core 运行 Bash 脚本时发生。

以上是关于standard_init_linux.go:178: exec 用户进程导致“exec 格式错误”的主要内容,如果未能解决你的问题,请参考以下文章