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