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 when start watching folder containing resolv.conf #462

Closed
lstocchi opened this issue Jan 21, 2025 · 6 comments · Fixed by #463
Closed

Error when start watching folder containing resolv.conf #462

lstocchi opened this issue Jan 21, 2025 · 6 comments · Fixed by #463

Comments

@lstocchi
Copy link
Collaborator

#450 added a watcher to start watching the directory containing the resolv.conf file to be up to date of the name servers defined in it.

However it may fails at setting the watcher and resulting in gvproxy to not starting as it should.

On MacOS, I have the symlink /etc/resolv.conf -> /private/var/run/resolv.conf. When, inside ../var/run, there is the symlink docker.sock -> /Users/luca/.local/share/containers/podman/machine/podman.sock I face a gvproxy exiting: cannot add network services: adding watcher failed: "/private/var/run/docker.sock": no such file or directory. If the symlink is removed, everything works as expected.

@cfergeau
Copy link
Collaborator

Does /Users/luca/.local/share/containers/podman/machine/podman.sock exist?
https://github.com/fsnotify/fsnotify/blob/a9bc2e01792f868516acf80817f7d7d7b3315409/backend_kqueue.go#L392-L397 has some code to ignore non existent symlinks, dunno why it does not trigger here

@cfergeau
Copy link
Collaborator

cfergeau commented Jan 21, 2025

@fatanugraha for what it's worth, there are still some issues after your file watch changes :(

@lstocchi
Copy link
Collaborator Author

@cfergeau yes it exists

@fatanugraha
Copy link
Contributor

fatanugraha commented Jan 21, 2025

Ouch, let me reproduce and see if i can think of any quick fix for this.

@fatanugraha
Copy link
Contributor

fatanugraha commented Jan 21, 2025

By adding the code below into the test

	_, err := net.Listen("unix", filepath.Join(dir, "lol.sock"))
	if err != nil {
		panic(err)
	}
	panic(dir)

	os.Symlink(filepath.Join(dir, "non-existent"), filepath.Join(dir, "hehe2"))
	os.Symlink(filepath.Join(dir, "lol.sock"), filepath.Join(dir, "hehe"))

I'm not able to reproduce the exact error but I got this error when i created a symlink to a socket.

        	Error Trace:	/Users/fatanugraha/fun/gvisor-tap-vsock/pkg/utils/filewatcher_test.go:45
        	Error:      	Received unexpected error:
        	            	adding watcher failed: "/Users/fatanugraha/Desktop/hehe": operation not supported on socket

after a quick skim into fsnotify code, it doesn't seem to have any check on the destination file after resolving the link and they don't expose any useful options that we can use to workaround this error :/

If fsnotify/fsnotify#661 is resolved we can add the watch to /etc (rather than /private/var/run) which can be also a good workaround.

@Luap99
Copy link
Member

Luap99 commented Jan 23, 2025

This was also reported on the podman repo: containers/podman#25103

Luap99 added a commit to Luap99/libpod that referenced this issue Feb 3, 2025
The current macos installer gvproxy version has a number of issues
around dns handling[1,2]. They should be fixed now in 0.8.3 as they
reverted the dns changes back to the 0.7.5 code. This should make it
work like it used to be. Our 5.3.2 installer ships the 0.7.5 version so
users of the podman installer never noticed that but we got plenty of
reports from brew users. This needs to be backported into v5.4 to make
sure we do not ship the broken version as part of the installer.

[1] containers/gvisor-tap-vsock#462
[2] containers/gvisor-tap-vsock#466

Signed-off-by: Paul Holzinger <[email protected]>
openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/podman that referenced this issue Feb 3, 2025
The current macos installer gvproxy version has a number of issues
around dns handling[1,2]. They should be fixed now in 0.8.3 as they
reverted the dns changes back to the 0.7.5 code. This should make it
work like it used to be. Our 5.3.2 installer ships the 0.7.5 version so
users of the podman installer never noticed that but we got plenty of
reports from brew users. This needs to be backported into v5.4 to make
sure we do not ship the broken version as part of the installer.

[1] containers/gvisor-tap-vsock#462
[2] containers/gvisor-tap-vsock#466

Signed-off-by: Paul Holzinger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants