standard_init_linux.go:178: exec user process caused "exec format error"

Question

docker started throwing this error:

standard_init_linux.go:178: exec user process caused "exec format error"

whenever I run a specific docker container with CMD or ENTRYPOINT, with no regard to any changes to the file other then removing CMD or ENTRYPOINT. here is the docker file I have been working with which worked perfectly until about an hour ago:

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

Answer 1

I forgot to put

#!/bin/bash

at the top of the sh file, problem solved.

Answer 2

This can happen if you're trying to run an x86 built image on an arm64/aarch64 machine.

You'll need to rebuild the image using the corresponding architecture

Answer 3

Add this code

#!/usr/bin/env bash

at the top of your script file.

Answer 4

This error could also occur if an image was built on a MacBook Pro with a Apple M1 Pro chip, which is ARM-based, so by default the Docker build command targets arm64 .

Docker in fact detects the Apple M1 Pro platform as linux/arm64/v8

Specifying the platform to both the build command and version tag was enough:

# 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 .

Environment

Chip: Apple M1 Pro, 10 Cores (8 performance and 2 efficiency)
Docker version 20.10.12, build e91ed57

Answer 5

If the Docker image is built on an M1 chip and uploaded to be deployed by Fargate then you'll notice this container error in Fargate:

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

There's a couple ways to work around this. You can either:

• Build your docker image using:

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

• Update your Dockerfile's FROM statements with

FROM --platform=linux/amd64 BASE_IMAGE:VERSION

Answer 6

Got the same Error, i was building ARM image after changing to AMD. Issue Fixed

That error usually means you're trying to run this amd64 image on a non-amd64 host (such as 32-bit or ARM).

TRY BUILDING by using buildx and specifying --platform linux/amd64

Sample Command

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

Answer 7

Another possible reason for this could be if the file is saved with Windows line endings (CRLF). Save it with Unix line endings (LF) and the file will be found.

Answer 8

Extending to the accepted answer:

For an alpine (without bash) image:

#!/bin/ash

at the top of the sh file, solves the problem.

Answer 9

For those trying to build images for aarch64 or armv7l architectures on amd64 Linux system and running into the same error: check if qemu-user-static package is installed. If not, install it with sudo apt install qemu-user-static on Ubuntu/Debian/Mint etc, or with sudo dnf install qemu-user-static on Fedora

Answer 10

None of this worked for me. Why is no one mentioning the BOM ?

This error occurs if you have a Byte Order Mark at the start of your file.

You can check with :

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

In Notepad++ you can save text in UTF-8 without the BOM by selecting the appropriate option in the Encoding menu:

Encoding > UTF-8

Answer 11

If you're getting this in AWS ECS, you probably built the image with an Apple M1 Pro chip. In your Dockerfile, you can add the following: FROM --platform=linux/amd64 <image>:<tag> .

If you're using a sub-image, ex: FROM <parent_image_you_created>:<tag> you'll want to make sure the <parent_image_you_created>:<tag> was built with FROM --platform=linux/amd64 <image>:<tag> .

Answer 12

I have faced same issue in RHEL 7.3, docker 17.05-ce when running offline loaded image. It appeared the default storage driver of RHEL/CentOS changed from device-mapper to overlay. Reverting back the driver to devicemapper fixed the problem.

dockerd --storage-driver=devicemapper

or

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

Answer 13

One more possibility is that #!/bin/bash is not in the very first line. There must be really nothing before it (no empty lines, nothing).

Answer 14

Not a direct answer to the question asked. Although I got the error while calling "docker-compose up" to bring my nodejs application up. Realized that in my "Dockerfile" i had CMD ["./server.js"] .

To fix i replaced it with CMD ["npm","start"] and that solved the issue. Hope if someone lands here for this exception may find this useful.

Answer 15

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

Answer 16

If you are using an IBR1700 router which runs containers, you may get a similar error when in the router command line after using command container logs test (where test is the name of the container).

To fix this you need to build the application so it runs on a different platform. It uses 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

Pushing to the repository with this build means it can run on the router.

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

Answer 17

For me, my ECS cluster was arm64 architecture, but my docker image was showing amd64 architecture. I rebuilt my docker image: https://docs.docker.com/desktop/multi-arch/

Answer 18

I had similar problem standard_init_linux.go:228: exec user process caused: exec format error , but nothing helped from the answers. Eventually i found that it was old docker version 17.09.0-ce which is also default on the Circle CI, so just after changing it to the most recent one problem was solved.

Answer 19

standard_init_linux.go:228: exec user process caused: exec format error For me, it's because there is no main package in my go project. Hope it helps someone.

Answer 20

I'm currently rocking an M1 Mac, I was also running into this issue a little earlier. I actually realized a Fargate task that I had deployed as part of a stack, had not been running for over a month because I had deployed it on my M1 Mac laptop. The deploy script was working fine on my old Intel-based Mac.

The error I was just noticing in the CW logs (again the task had been failing for over a month) was just exactly as follows:

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

To fix it, in all the docker build steps -- since I had one for building a lambda layer, and another for building the Fargate task -- I just updated to add the --platform=linux/amd64 . Please note, it did not work for me if I for added the tag after the -t argument, for example like img-test:0.1-amd64 . I wonder if perhaps that could be because I was referencing the :latest tag later in my script.

In any case, these were the changes necessitated. You'll notice, all I really did was add the --platform argument; everything else stayed the same.

ecr_repository="some/app"

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

And I'm not sure if it's technically required, but just to be on the safe side, I also updated all the FROM statements in my Dockerfile s:

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