Moby: Docker for Mac: standard_init_linux.go:175: exec user process caused "exec format error"

Created on 22 Jun 2016  Â·  31Comments  Â·  Source: moby/moby

Output of docker version:

$ docker version
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:35:33 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:45:29 2016
 OS/Arch:      linux/amd64

Output of docker info:

$ docker version
Client:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:35:33 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc2
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   906eacd
 Built:        Fri Jun 17 20:45:29 2016
 OS/Arch:      linux/amd64
mdesales@Marcello-New2015 [06/22/201611:00:19] ~/dev/github/public/docker/example-voting-app (master *) $ docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 28
Server Version: 1.12.0-rc2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 65
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay null bridge host
Swarm: inactive
Runtimes: default
Default Runtime: default
Security Options: seccomp
Kernel Version: 4.4.13-boot2docker
Operating System: Boot2Docker 1.12.0-rc2 (TCL 7.1); HEAD : 52952ef - Fri Jun 17 21:01:09 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.9 MiB
Name: manager1
ID: UT7Z:UE6B:275T:AALD:N43H:WB45:7TJL:KUFH:IGGB:JEPS:SRGR:LV7L
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 51
 Goroutines: 180
 System Time: 2016-06-22T17:53:54.129259814Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):

Trying to run on the native Docker for Mac 10.11.5.

$  sw_vers -productVersion
10.11.5

$ docker run --rm -p 8083:8000 hypriot/rpi-whoami
standard_init_linux.go:175: exec user process caused "exec format error"

Steps to reproduce the issue:

  1. Install Docker for Mac
  2. Try to run a command that binds a port number

Describe the results you received:

The following error was printed:

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

Describe the results you expected:

The process should be running...

Additional information you deem important (e.g. issue happens only occasionally):

platfordesktop versio1.12

Most helpful comment

I was able to resolve this error for my docker container by adding a Sha-Bang on top of the shell script that I was trying to run as CMD in dockerfile

!/bin/bash

All 31 comments

seeing the same thing

You need to issue a shell command. Like bash at the end of the statement.

I also issue similar has occurred. old postgres image.
I was solved docker pull try the recent docker images.

Looks like it's not running Raspberry Pi images. I know this was an "undocumented" feature, so not sure something changed in that area

ping @avsm @justincormack any idea if something changed?

Seems that the image is using the FROM scratch directive which is missing the qemu binary needed to run it under docker for mac.
https://github.com/hypriot/rpi-whoami

cc @StefanScherer @DieterReuter

Docker for Mac is able to run Raspberry Pi images (and others) if the image contains the qemu binary. The rpi-whoami is supposed to be a very small image lacking other binaries, so this does not work out of the box with Docker for Mac.

But try one of the resin/rpi-raspbian based images, these will work. Eg. docker run --rm -it resin/rpi-raspbian uname -a

Maybe Docker for Mac magically mounts the qemu binary in the future into the container so that every image just works :-)

@StefanScherer thanks! yes, I think @justincormack was thinking of doing that, but it's not there yet.

Following the above discussion, this doesn't look to be a bug in Docker, so I'll close this, but feel free to continue the discussion

@thaJeztah @StefanScherer I would be glad to have those suggestions... This should be transparent for Mac users having that Docker can run anything anywhere :)

Yes we are planning to make it fully transparent in future.
On 12 Jul 2016 00:05, "Marcello de Sales" [email protected] wrote:

@thaJeztah https://github.com/thaJeztah @StefanScherer
https://github.com/StefanScherer I would be glad to have those
suggestions... This should be transparent for Mac users having that Docker
can run anything anywhere :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/docker/issues/23865#issuecomment-231891699,
or mute the thread
https://github.com/notifications/unsubscribe/AAdcPCL5eqh1gY1Y37YYVGNoaGSBlhgVks5qUswigaJpZM4I8Dmq
.

What will be the W/A for now?
I'm running on 1.12 rc4-beta20 for MAC. See same symptoms.

I'm seeing the same symptom from packaging a go application

@archyufa @perrohunter build from an image that supports qemu binary, such as the resin/rpi-raspbian based images mentioned above.

Besides OS X this also happens on Linux Mint 17.3 while running a static compiled Go binary in a Docker scratch container:

Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 22:00:36 2016
 OS/Arch:      linux/amd64

@marcellodesales please (re)open this issue, guess it's closed by closing https://github.com/hypriot/rpi-whoami/issues/2.

Besides OS X this also happens on Linux Mint 17.3 while running a static compiled Go binary in a Docker scratch container:

How did you compile the binary? If you compiled the binary on OS X, it may still be an invalid binary to run on Linux. What happens if you add that binary to a non-scratch image (e.g. alpine or ubuntu), and run the binary from an interactive shell?

@thaJeztah we compile it static in golang:latest by _Drone CI_:

build:
  image: golang:latest
  environment:
    - GO15VENDOREXPERIMENT=1
    - CGO_ENABLED=0
    - GOOS=linux
    - GOARCH=amd64
  commands:
    - go get -v ./
    - go test -v ./
    - go build -a -v -o ./.drone/srv-product/build/srv-product ./

Tried to add it in alpine:3.4 which isn't working:

standard_init_linux.go:175: exec user process caused "no such file or directory"

Tried to install qemu in alpine:3.4 and add the static binary as well which isn't working as well (same error).

I'm going to add glibc in alpine:3.4 and keep you posted. I will add the static bin to golang:latest as well.

I got the similar error on a standalone Odroid c2 as well.
standard_init_linux.go:175: exec user process caused "exec format error" The command '/bin/sh -c touch /kube-build-image' returned a non-zero code: 1
I am trying to compile kubernetes on the odroid, and seems the /bin/sh -c touch /kube-build-image line should be /bin/sh -c "touch /kube-build-image" and that should have the problem fixed by adding those quotes

I'm also having this issue on macos, even basing it on either resin/rpi-raspbian or resin/raspberrypi3-node.

Same here...

docker version
Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 14:58:48 2016
 OS/Arch:      linux/arm

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 14:58:48 2016
 OS/Arch:      linux/arm

docker info
Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 52
Server Version: 1.12.0-rc3
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host overlay
Swarm: active
 NodeID: bwi2ypaaeoucvmzzpww0aynhe
 IsManager: Yes
 Managers: 1
 Nodes: 3
 CACertHash: sha256:2e89359de883dc71c6ea52ea218de6f820c9e899be76b68a726abffada835ada
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 4.4.15-hypriotos-v7+
Operating System: Raspbian GNU/Linux 8 (jessie)
OSType: linux
Architecture: armv7l
CPUs: 4
Total Memory: 862 MiB
Name: pi1
ID: W2S2:C4RD:QPXV:OAKE:BDGW:X7ZG:TVZC:ANU7:SH4K:UXY2:ERCR:JSAV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No cpuset support
Insecure Registries:
 127.0.0.0/8

Errors:

docker-compose up
Starting dockertree_storage_1
Starting dockertree_agent_1
Attaching to dockertree_storage_1, dockertree_agent_1
storage_1  | standard_init_linux.go:175: exec user process caused "exec format error"
agent_1    | standard_init_linux.go:175: exec user process caused "exec format error"
dockertree_storage_1 exited with code 1
dockertree_agent_1 exited with code 1

Why is this issue closed, it seems like folks are still hitting it.
Can someone clarify what the problem is?

I'm also hitting this on a Mac when building a go static binary and adding it FROM scratch to a docker container.

I was able to resolve this error for my docker container by adding a Sha-Bang on top of the shell script that I was trying to run as CMD in dockerfile

!/bin/bash

@tompscanlan I ran into this and realized I was building the go executable on my Mac and then trying to run it in an Ubuntu container. Updating the build command to the following fixed the issue.

env GOOS=linux GOARCH=386 go build

@chaslemley agreed. I've since found that verifying the enclosed binary is built statically for the correct base OS seems to fix this problem.

Had this issue.
Was the result of a noob space at the beginning of my entrypoint script
#!/bin/bash

There also may be a BOM signature sitting at the beginning of your file.

Use :set nobomb and :w in vim to remove that.

One of the reasons why this error could happen is line endings

If you are on Windows, make sure that your custom entrypoint file uses LF (Unix style) line endings, not CRLF (Windows style line endings).

It could happen if you created entrypoint file on Windows, or checked out it from Git repository on Windows (it converts line endings LF to CRLF by default on Windows).

I just ran into this issue. @holygits What .sh script has a space in it?

@dalenoe, I think he is talking about his own script.

@dalenoe the shebang line of my entrypoint script looked like " #!/bin/bash" as opposed to "#!/bin/bash"

I just ran into this issue.

https://github.com/scaleway/image-ubuntu/issues/98
@bchatelard 's reply helped me.

I replaced titi(x86) with titi-armhf in my dockerfile, container run.

Just encountered this issue as well. Ended up being a layer that wasn't pulled properly. Running docker system prune --all and re-pulling the image fixed the issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cefn picture cefn  Â·  3Comments

surlymo picture surlymo  Â·  3Comments

bhuvan picture bhuvan  Â·  3Comments

ailjushkin picture ailjushkin  Â·  3Comments

karellm picture karellm  Â·  3Comments