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

Error in docker-slim build #59

Closed
Smolevich opened this issue Dec 29, 2018 · 21 comments
Closed

Error in docker-slim build #59

Smolevich opened this issue Dec 29, 2018 · 21 comments

Comments

@Smolevich
Copy link

docker:

Client: Docker Engine - Community
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:47:43 2018
OS/Arch: darwin/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:55:00 2018
OS/Arch: linux/amd64
Experimental: false

docker-slim version:

darwin|Tetra|1.22-1-g2b02487|2b02487d633ef0b974978ab1a8a2fed099226ad6|2018-12-27_11:17:50AM (go1.11.4)

Binary files appeared in /usr/local/bin directory

After run command docker-slim --debug build --http-probe --include-path /etc/passwd php:7.3-cli
fails with error

The path /usr/local/bin/docker-slim-sensor
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.``` 

@kcq
Copy link
Member

kcq commented Dec 31, 2018

Thanks a lot for opening the issue! I wonder if you have anything else printed to the console when you run the command. Looks like the sensor volume failed to mount in the container when DockerSlim was trying to analyze the image.

@marceloboeira
Copy link

I had the same issue... my solution was to copy the binary to the folder I was (which probably had the permissions to create the .images/ folder and mount...) I guess it's a permission issue.

@Smolevich
Copy link
Author

On mac os docker-slim work, but on linux build fails
docker-slim version:

docker-slim:
linux|Tetra|1.22|936f91d2f1f3fc9b09f94e6ce908135108696675|2018-09-08_02:00:42AM (go1.10)
host:
OsName=Alpine Linux 3.8.2
OsBuild=
Version=#1 SMP Tue Nov 13 16:18:09 EST 2018
Release=4.19.2-1.el7.elrepo.x86_64
Sysname=Linux
docker:
Name=k8s-n01
KernelVersion=4.19.2-1.el7.elrepo.x86_64
OperatingSystem=CentOS Linux 7 (Core)
OSType=linux
ServerVersion=17.12.1-ce
Architecture=x86_64
ApiVersion=1.35
MinAPIVersion=1.12
BuildTime=2018-02-27T22:17:54.000000000+00:00
GitCommit=7390fc6

I run same command
Part of output :

docker-slim[build]: state=inspecting.container
time="2019-01-10T07:59:13Z" level=info msg="starting instrumented 'fat' container..." app=docker-slim command=build 
time="2019-01-10T07:59:13Z" level=debug msg="RunContainer: default exposed ports => %#vmap[65501/tcp:{} 65502/tcp:{}]" 
time="2019-01-10T07:59:13Z" level=info msg="RunContainer: created container => c86391be7ae9c6f51f3743c5521f7dcba503bb7683fab91f73e28b49c2df2a3c" 
time="2019-01-10T07:59:15Z" level=fatal msg="docker-slim: failure" error="API error (400): {"message":"OCI runtime create failed: container_linux.go:348: starting container process caused \"exec: \\\"/opt/dockerslim/bin/sensor\\\": permission denied\": unknown"}
" stack="goroutine 1 [running]:
runtime/debug.Stack(0x28, 0xc4200187e0, 0xc4201f6000)
	/usr/local/go/src/runtime/debug/stack.go:24 +0xa7
github.com/docker-slim/docker-slim/pkg/utils/errutils.FailOn(0x8b70c0, 0xc4203575a0)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/pkg/utils/errutils/errutils.go:14 +0x51
github.com/docker-slim/docker-slim/internal/app/master/commands.OnBuild(0x0, 0x0, 0x86c901, 0x0, 0x0, 0xc42010a1e0, 0x7fff48fd64a7, 0x2c, 0x0, 0x0, ...)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/internal/app/master/commands/build.go:115 +0xc7a
github.com/docker-slim/docker-slim/internal/app/master.init.0.func5(0xc42020a140, 0x100, 0xc42020a140)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/internal/app/master/cli.go:480 +0xd68
github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli.HandleAction(0x7cf9a0, 0x882a00, 0xc42020a140, 0xc4200ec100, 0x0)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli/app.go:485 +0xc8
github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli.Command.Run(0x8673b3, 0x5, 0x0, 0x0, 0xc420125150, 0x1, 0x1, 0x87c272, 0x3e, 0x0, ...)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli/command.go:207 +0xa37
github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli.(*App).Run(0xc420138b60, 0xc420116000, 0x7, 0x7, 0x0, 0x0)
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/vendor/github.com/codegangsta/cli/app.go:250 +0x700
github.com/docker-slim/docker-slim/internal/app/master.runCli()
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/internal/app/master/cli.go:730 +0x55
github.com/docker-slim/docker-slim/internal/app/master.Run()
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/internal/app/master/app.go:6 +0x25
main.main()
	/Users/q/docker-slim/docker-slim/_gopath/src/github.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x20
" version="linux|Tetra|1.22|936f91d2f1f3fc9b09f94e6ce908135108696675|2018-09-08_02:00:42AM (go1.10)" 

@kcq
Copy link
Member

kcq commented Feb 20, 2019

@marceloboeira thanks for adding a comment about your own experience! It's super helpful! Where was the binary originally when it failed to work?

@kcq
Copy link
Member

kcq commented Feb 20, 2019

@Smolevich where is the docker-slim binary located on your system? Just to confirm, your host OS is Alpine Linux, right?

@Ladicle
Copy link

Ladicle commented Mar 6, 2019

I have the same issue. the docker-slim build command tries to make .images directory in the same place the docker-slim. I installed it in the /usr/local/bin, but the path is not allowed mount by the Docker for Mac. if I move it to the /tmp/docker-slim, it's working well.

@Ladicle
Copy link

Ladicle commented Mar 6, 2019

does docker-slim have the option to change the path which creating .images directory? --state-path options seems like for that, but it's not working in my environment.

@kcq
Copy link
Member

kcq commented Mar 13, 2019

@Ladicle Yes, the --state-path flag is meant to address this problem. What's the OS inside your Docker images?

@kcq
Copy link
Member

kcq commented Mar 13, 2019

@marceloboeira If the docker-slim binary is not located in a directory where it can't new create directories and files you you'll get a runtime error. The --state-path flag allows you to specify an alternative location for DockerSlim to keep its state information (including the artifacts it generates). What's your host OS? Are you running it on Linux? If so, what distro?

@Ladicle
Copy link

Ladicle commented Mar 13, 2019

@kcq I used golang:1.12.0 image, so the base image is alpine:3.9.

when I set /tmp to the --state-path, artifactsPath uses it but sensorPath use the directory in which binary locates.

[+] Local
  [-] i=<*github.com/docker-slim/docker-slim/internal/app/master/inspectors/container.Inspector>(0xc0002ec000)
  [-] ~r0=<error>
  [.] sensorPath="/usr/local/go/src/github.com/docker-slim/docker-slim/cmd/docker-...+23 more"
  [.] sensorMountInfo="/usr/local/go/src/github.com/docker-slim/docker-slim/cmd/docker-...+53 more"
  [-] artifactsPath="/tmp/.images/cee68f119e197c3076411ceefb2c72bdf5f701fa2f3b57f5f45...+23 more"
  [-] artifactsMountInfo="/tmp/.images/cee68f119e197c3076411ceefb2c72bdf5f701fa2f3b57f5f45...+49 more"
  [-] volumeBinds=<[]string> (length: 824634311168, cap: 824635685976)
[+] Global
  [-] ErrStartMonitorTimeout=<error>

@Ladicle
Copy link

Ladicle commented Mar 13, 2019

Is it better to move the sensor binary to the safe path like /tmp... ?

@kcq
Copy link
Member

kcq commented Mar 13, 2019

@Ladicle Thanks for the extra info! The sensorPath is just the location where the sensor binary is located. It doesn't require write permissions for that location. It mounts it as a read-only volume into the container it creates. Which version of Mac OS X are you using?

@Ladicle
Copy link

Ladicle commented Mar 13, 2019

@kcq thank you for your response. I'm using the latest MacOS(Mojave Version 10.14.3).

@Ladicle
Copy link

Ladicle commented Mar 15, 2019

sensorMountInfo normally has a :ro suffix, so I'll report about this diagnosis to the docker for mac.

When a docker command mounts with -v option, it shows the File Sharing error. However, when it mounts with --mount option, it shows no such file or directory. In fact, the target directory which is bound /usr/local/bin did not any binaries in the source path(it does not occured outside of /usr/local/bin, and no problem on Linux).

@Ladicle
Copy link

Ladicle commented Mar 15, 2019

ref: docker/for-mac#3582

@kcq
Copy link
Member

kcq commented Mar 15, 2019

Thanks for the reference @Ladicle! Wonder if it's security related somehow. Doesn't look like it's limited to Mojave (I was able to repro it with an older version of Mac OS X (10.11)).

@kcq
Copy link
Member

kcq commented Mar 15, 2019

@Ladicle turns out it's related to how Docker for Mac shares its local files with the VM. If you open the File Sharing tab in Docker Preferences you'll see a list of directories it shares, so you can mount files from any of these directories or sub-directories. /usr/loca/bin/ is not on the list and if you try to add it (or its parent, /usr/local/) it won't do it saying that the path is reserved by Docker...

I'll add a little hack to detect the /usr/local/bin installation on Macs, so the master copies the sensor app to the /tmp directory (one of the shared directories by default) setting the state path to the same location too.

@kcq
Copy link
Member

kcq commented Mar 16, 2019

The enhancement is in... and it will be available in the next release (1.25) or you can build it yourself if you don't want to wait :-)

@kcq kcq added DONE and removed WIP labels Mar 16, 2019
@Ladicle
Copy link

Ladicle commented Mar 17, 2019

Thanks, @kcq. it worked well!

@kcq
Copy link
Member

kcq commented Mar 19, 2019

There'll be 1.24.2 released in the next day, so there's no need to wait for 1.25 :-)

@kcq
Copy link
Member

kcq commented Mar 26, 2019

1.24.2 is out :)

@kcq kcq closed this as completed Mar 26, 2019
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

4 participants