Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
marcellodesales opened this issue Jun 22, 2016 · 31 comments

Comments

@marcellodesales
Copy link

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

@quasiben
Copy link

seeing the same thing

@k2xl
Copy link

k2xl commented Jun 22, 2016

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

@uzyexe
Copy link

uzyexe commented Jun 27, 2016

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

@thaJeztah
Copy link
Member

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?

@FrenchBen
Copy link
Contributor

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

@StefanScherer
Copy link
Contributor

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

@thaJeztah
Copy link
Member

@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

@marcellodesales
Copy link
Author

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

@justincormack
Copy link
Contributor

Yes we are planning to make it fully transparent in future.
On 12 Jul 2016 00:05, "Marcello de Sales" notifications@github.com 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
#23865 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAdcPCL5eqh1gY1Y37YYVGNoaGSBlhgVks5qUswigaJpZM4I8Dmq
.

@archyufa
Copy link

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

@perrohunter
Copy link

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

@FrenchBen
Copy link
Contributor

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

@bkleef
Copy link

bkleef commented Aug 15, 2016

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

@bkleef
Copy link

bkleef commented Aug 15, 2016

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

@thaJeztah
Copy link
Member

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?

@bkleef
Copy link

bkleef commented Aug 15, 2016

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

@ip4368
Copy link

ip4368 commented Aug 21, 2016

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

@fsamir
Copy link

fsamir commented Aug 24, 2016

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

@mjudeikis
Copy link

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

@tompscanlan
Copy link

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.

@hshira
Copy link

hshira commented Sep 8, 2016

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

@chaslemley
Copy link

@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

@tompscanlan
Copy link

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

@jordy25519
Copy link

jordy25519 commented Sep 20, 2016

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

@mayask
Copy link

mayask commented Dec 26, 2016

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

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

@jazzfog
Copy link

jazzfog commented Apr 16, 2017

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

@dalenoe
Copy link

dalenoe commented May 29, 2017

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

@jazzfog
Copy link

jazzfog commented May 29, 2017

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

@jordy25519
Copy link

jordy25519 commented May 29, 2017

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

@yicone
Copy link

yicone commented Jul 19, 2017

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.

@bmancini55
Copy link

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.

mattfenwick added a commit to blackducksoftware/perceptor-skyfire that referenced this issue Oct 31, 2018
to fix 'standard_init_linux.go:178: exec user process caused "exec format error"' errors

based on: moby/moby#23865 (comment)
rdkls added a commit to rdkls/docker-aws-dashing that referenced this issue Dec 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests