search

docker / for-mac

Bug reports for Docker Desktop for Mac
https://www.docker.com/products/docker#/mac
2.43k stars 118 forks source link

With `VirtioFS`, I see socket messages starting with 4.15 #6651

Closed ericvn closed 1 year ago

ericvn commented 1 year ago

Expected behavior

No warning messages starting our build-tools container

Actual behavior

I see two messages:

cp: cannot stat '/config/.docker/run/docker.sock': No such file or directory
cp: cannot stat '/config/.docker/run/docker-cli-api.sock': No such file or directory

Information

Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check

Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0038: is the connection to Docker working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?
No fatal errors detected.

Steps to reproduce the behavior

  1. Make sure that VirtioFS is specified.
  2. Pull the istio/istio repo
  3. Make sure Docker Desktop and make are installed.
  4. Run make shell. This should yield a shell prompt. It does for versions prior to 4.15, but with 4.15 and a later build mention in roadmap issue 7, I see the two messages above.
ericvn commented 1 year ago

With the release of 4.16, the warnings are now:

su-exec: setgroups(0): Operation not permitted
su-exec: setgroups(0): Operation not permitted
chmod: changing permissions of '/config-copy': Operation not permitted
su-exec: setgroups(0): Operation not permitted
su-exec: setgroups(0): Operation not permitted
cp: cannot stat '/config-copy/*': No such file or directory
fredericdalleau commented 1 year ago

Hi @ericvn, could share the command lines that creates those warning? I reproduced them with grpcfuse in lieu of virtiofs, so the cause is to be found elsewhere.

ericvn commented 1 year ago

@fredericdalleau I agree that the messages also show up if I select gRPC or VirtioFS.

The easiest way to see these warnings is to git clone our GitHub repository and then run a command there. Try doing a git clone git@github.com:istio/istio.git (or similar command to get the repo). Then in the root directory, run a make clean or make shell which will leave you at a prompt inside the container).

ericvn commented 1 year ago

@fredericdalleau I am also in the Docker Community Slack as @ericvn.

ericvn commented 1 year ago

Looks to be related to the use of su-exec with 4.16. With 4.15, even though docker run -u ... was specified, su-exec 0:0 ls would work within the shell. After updating to 4.16, the su-exec now fails with a su-exec: setgroups(0): Operation not permitted.

If I remove the -u on the docker command, su-exec 0:0 works.

ericvn commented 1 year ago

Docker issue on sudo, and seems related, issue with 4.16.0: https://github.com/docker/for-mac/issues/6675

ericvn commented 1 year ago

su-exec related failure fixed in 4.16.1.

ericvn commented 1 year ago

@fredericdalleau Not sure if I need to respond here as Wike sent a note that there is some question which I still haven't responded to.

Status: If you pull the latest istio/istio and try to recreate this on Docker for Mac Desktop 4.16.1, you will no longer see any errors if you are on the master branch.. This is because I updated the build-tools image to no longer copy the .sock files since the errors occurred in 4.15 and 4.16. Note that this work around hasn't been merged to our release branches, so if you checkout the release-1.16 branch for example, you will see the error (cp: lines below).

> gco release-1.16
Switched to branch 'release-1.16'
Your branch is up to date with 'upstream/release-1.16'.
 ~/work/go/src/istio.io/istio  release-1.16 *1 ?7  git pull                                                                                                                                        
>  make clean 
Unable to find image 'gcr.io/istio-testing/build-tools:release-1.16-2def55c63b1dcafc9f32045c77468c321a045e48' locally
release-1.16-2def55c63b1dcafc9f32045c77468c321a045e48: Pulling from istio-testing/build-tools
bf065bceb8fc: Already exists
...
Status: Downloaded newer image for gcr.io/istio-testing/build-tools:release-1.16-2def55c63b1dcafc9f32045c77468c321a045e48
cp: cannot stat '/config/.docker/run/docker.sock': No such file or directory
cp: cannot stat '/config/.docker/run/docker-cli-api.sock': No such file or directory
rm -rf /work/out/darwin_amd64 /work/out/linux_amd64
fredericdalleau commented 1 year ago

@ericvn thanks for keeping that branch live. The ~/.docker/run/docker.sock from the host is not a valid file to use inside the VM. I see it is copied as part of your container startup procedure. Although those are visible in the directory listing, those are special files on the host, and cannot be used in the VM (This behavior can differ on native linux).

ericvn commented 1 year ago

@fredericdalleau I'm not totally familiar on why things were setup this way, but I believe it has to do with running the docker command within the build container. I would need to research again how the docker cli finds the socket. I know that there was a change earlier related to a raw version of the file that affected some of our users.

I did find a solution where we do not try and copy the files to another directory, and that gets rid of the socket messages. It sounds like I need to update all the release branches to not copy the file, or just have people ignore the messages.

docker-robott commented 1 year ago

There hasn't been any activity on this issue for a long time. If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment. If not, this issue will be closed in 30 days.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

ericvn commented 1 year ago

I did go back and test this again today. For the cases where the code was not updated to not try and copy the files to another directory, the socket messages still appear with Docker Desktop 4.18.0 (4.19.0 has another socket issue so have reverted back).

At this point, I don't expect that the issue will be fixed. I have a work-around and it doesn't sound like anyone else is worried about this problem.

ericvn commented 1 year ago

I will close this issue since we do have a work-around.

docker-robot[bot] commented 1 year ago

Closed issues are locked after 30 days of inactivity. This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked