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

score 488 · Accepted Answer · answered Feb 27 '17 at 20:14

488

I forgot to put

#!/bin/bash

at the top of the sh file, problem solved.

answered Feb 27 '17 at 20:14

Marcus Ruddick

9,795
7
28
43

8

Thanks! After an hour of hair pulling, and 10 times checking if the architectures (arm/x64 etc) match, your answer saved the day!. p.s.: For windows users like me creating a linux docker, dont forget to remove the windows newline (\r) characters from your file, otherwise the errors keep appearing! – Maarten Kieft Jun 08 '17 at 05:09
I got it working after using this solution, earlier I faced same issue. – akshat thakar Jun 23 '17 at 13:45
16

I had a space in front of my "#!/bin/bash" – ArunTejCh Nov 19 '17 at 05:44
I had somehow removed the `#` at the beginning of my entrypoint. What a time waste. – shredding Sep 04 '19 at 11:47
This isn't even Docker-specific, this just always happens when running a Bash script from .NET Core. – Andrew Koster Mar 18 '20 at 20:13
1

I am fairly new to docker can you please tell me where I need to put this in my DockerFile or in some other location. – Parth Kansara Nov 18 '21 at 05:40
2

Can someone add an explanation of what this is and why it worked? – Stevphen Jan 30 '22 at 09:54
Why need to it on top https://stackoverflow.com/q/8967902/1278112 – Shihe Zhang Mar 18 '22 at 02:16
in my case i added /bin/sh to my entrypoint.sh file and it worked! Thanks! – thangaraj Jun 06 '22 at 16:16

score 333 · Answer 2 · answered Oct 05 '20 at 19:39

333

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

answered Oct 05 '20 at 19:39

Alex Joseph

4,719
2
21
25

15

Thank you! I'd recently moved my docker stuff to Kubernetes on a raspberry pi - forgetting the different architecture - had to change all my images to use arm32v7 or arm64v8. You pointed me in the right direction! – MichaelEaton Nov 08 '20 at 19:48
Omg thank you so much, this is so obvious now but hadn't even occurred to me! – doz87 Mar 23 '21 at 12:04
1

How do you rebuild an image with a different architecture? – Jason Swett Jun 15 '21 at 12:31
1

@JasonSwett - Checkout multi-arch builds in docker: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ – Alex Joseph Jun 16 '21 at 07:28
2

As ARM gets more popular on development machines, and people try to deploy images to x86_64 instances, this will be very useful info! Thank you. – mkturner Aug 12 '21 at 22:16
48

If anyone has this problem when running the image on an x86 machine, build the docker image with `--platform linux/amd64`. – Stevan Nov 16 '21 at 14:10
Is it possible to run the container under emulation? – Keith Jan 27 '22 at 17:53
3

For me I was building image in Mac Apple Silicon(arm) and running on a x86(amd) EC2. Hopefully a lesson and I would pick this mistake much quicker next time :) – Chaminda Aug 03 '22 at 23:25
1

If you are running ```k8s```, you can check your arc ```kubectl describe nodes``` and look out for ```Architecture: ``` – Margach Chris Nov 21 '22 at 12:52
saved my day! I was trying to push to ECS and forgot this step. – A Simple Programmer Feb 10 '23 at 18:29

rbento · Answer 3 · 2022-03-12T06:28:36.913

213

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

edited Mar 12 '22 at 06:28

answered Feb 13 '22 at 15:31

rbento

9,919
3
61
61

1

ure a life saver man!, I was suffering with that error and performing the references that u shared, worked like a charm! `ProductName: macOS, ProductVersion: 12.1, BuildVersion: 21C52` – Manuel Lazo Jun 26 '22 at 02:22
This wasn't enough. I needed to add the platform also to my `FROM` imports like `FROM amd64/python:3.9-slim` and only then I could successfully build a dockerfile for AMD on Apple M1 Pro with the command given above. – asmaier Sep 09 '22 at 15:39
When the deployment still doesn't work, delete all images for other platforms. – user1961312 Oct 27 '22 at 10:06
Is `` in `:-amd64` is Docker version(20.10.12).. right? – Jade Han Nov 20 '22 at 17:03
@JadeHan No, it should be your image version, like so: `docker pull rodbento/webapp:1.0.0-arm64` – rbento Nov 20 '22 at 17:06

score 86 · Answer 4 · edited May 31 '22 at 19:44

86

Add this code

#!/usr/bin/env bash

at the top of your script file.

edited May 31 '22 at 19:44

Josh Correia

3,807
3
33
50

answered Feb 27 '19 at 09:19

rainstop3

1,408
11
13

1

@akki the entrypoint needs to be executable. If the initial shell file was not, that caused the error. – jjmerelo Mar 03 '20 at 09:09
2

@jjmerelo I disagree: in the case when file is not executable – you get a different error, saying "not enough permissions". – Innokenty Nov 17 '20 at 17:15

score 83 · Answer 5 · answered Jan 06 '22 at 22:17

83

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

answered Jan 06 '22 at 22:17

Ryan

1,482
2
11
19

I am facing the same issue, but didn't solved yet. – Rudrakshya Barman Feb 03 '22 at 04:25
1

Thank you so much it worked with me using only this cmd : docker buildx build --platform=linux/amd64 -t image-name:version . – Abderrahim May 14 '23 at 19:15

score 53 · Answer 6 · edited Feb 21 '22 at 15:52

53

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

edited Feb 21 '22 at 15:52

grizzthedj

7,131
16
42
62

answered May 29 '21 at 19:50

Ranjithkumar MV

804
8
10

Thanks a lot, your answer save me a lot of time! – mcgusty Apr 17 '22 at 13:06

score 26 · Answer 7 · answered Jun 26 '22 at 00:45

26

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

answered Jun 26 '22 at 00:45

ksealey

1,698
1
17
16

Thank you! not sure why there is no hint of this in the error, or on the ECS Console, or the AWS documentation – Nima Jul 24 '22 at 14:10

score 13 · Answer 8 · answered Nov 06 '17 at 18:41

13

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.

answered Nov 06 '17 at 18:41

Ryan Allen

5,414
4
26
33

Nice catch! Make sure your file changes make it into the image (ex: rebuild) before you run it again. – Miguel Pereira Jan 06 '22 at 23:42
Using Visual Studio Code on Windows there is a setting for default end of line character - turn auto off and set to \n – brianlmerritt Mar 06 '22 at 11:30

score 13 · Answer 9 · answered Nov 08 '18 at 13:13

13

Extending to the accepted answer:

For an alpine (without bash) image:

#!/bin/ash

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

answered Nov 08 '18 at 13:13

pme

14,156
3
52
95

score 13 · Answer 10 · answered Aug 18 '22 at 14:53

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 Dockerfiles:

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

score 5 · Answer 11 · answered Jan 19 '22 at 13:28

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

score 2 · Answer 12 · answered Dec 12 '17 at 13:47

2

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

answered Dec 12 '17 at 13:47

Omid

504
1
7
14

This was the only working solution for me. I prefer the config solution as the other one spawns a new active process and might only fix it temporally. – ST-DDT Jul 05 '18 at 12:05

score 2 · Answer 13 · answered Jan 17 '19 at 09:27

2

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

answered Jan 17 '19 at 09:27

Piotr Kepka

318
3
5

score 2 · Answer 14 · edited Feb 17 '19 at 03:35

2

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.

edited Feb 17 '19 at 03:35

Book Of Zeus

49,509
18
174
171

answered Feb 17 '19 at 02:43

Vijay Yadav

49
4

score 2 · Answer 15 · answered Mar 17 '22 at 10:04

2

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

answered Mar 17 '22 at 10:04

SaPropper

463
3
11

This one worked for me. Changed to normal UTF-8 encoding instead of UTF-8 BOM and it started working. – Benj Apr 13 '22 at 18:33

score 1 · Answer 16 · answered Jul 30 '22 at 12:24

1

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.

answered Jul 30 '22 at 12:24

zzzzzsy

31
1

score 1 · Answer 17 · answered Oct 28 '22 at 10:00

If you have buildx installed and still run into this error, it might be because cross-platform emulators are missing.

These can be installed like this:

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

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

Happened to me when trying to build a linux/arm64 image via Gitlab pipeline running on a Gitlab runner with platform linux/amd64.

score 0 · Answer 18 · answered Sep 13 '19 at 13:26

0

In my case, I "drained" my ECS instanced and "activated" them back again and thereafter the error vanished.

answered Sep 13 '19 at 13:26

Sudharsan S

51
1
3

score 0 · Answer 19 · answered May 25 '21 at 11:34

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

score 0 · Answer 20 · answered Sep 21 '21 at 17:52

0

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/

answered Sep 21 '21 at 17:52

Monica

11

score 0 · Answer 21 · answered Oct 28 '21 at 13:55

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.

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

21 Answers21

Linked

Related