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

时间:2017-02-27 20:08:54

标签: python linux bash docker

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"]

11 个答案:

答案 0 :(得分:103)

我忘记了

#!/bin/bash

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

答案 1 :(得分:9)

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

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

答案 2 :(得分:2)

另一个可能的原因可能是文件是使用Windows行结尾(CRLF)保存的。使用Unix行结尾(LF)保存它,然后找到该文件。

答案 3 :(得分:2)

添加此代码

   #!/usr/bin/env bash

在脚本文件的顶部。

答案 4 :(得分:2)

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

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

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

尝试构建

示例命令

$stmt = $mysqli->prepare("DELETE FROM api_keys WHERE api_key = ? LIMIT 1");
$stmt->bind_param("s", $_POST['api_key']);
$deleted = $stmt->execute();

if ($deleted) {
  echo "API Key Successfully Deleted.";      
}

答案 5 :(得分:1)

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

dockerd --storage-driver=devicemapper

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

答案 6 :(得分:0)

扩展到可接受的答案:

对于高山(无bash)图片:

re.sub
sh文件顶部的

解决了该问题。

答案 7 :(得分:0)

另一种可能性是#!/ bin / bash不在第一行。之前肯定没有任何东西(没有空行,没有任何东西)。

答案 8 :(得分:0)

不是所问问题的直接答案。尽管我在调用“ docker-compose up”以启动我的nodejs应用程序时遇到错误。意识到在我的“ Dockerfile”中,我有CMD ["./server.js"]

要解决此问题,我将其替换为CMD ["npm","start"],从而解决了该问题。希望有人登陆此异常可能会发现它有用。

答案 9 :(得分:0)

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

答案 10 :(得分:0)

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