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

MacOS: attaching to namespace forbidden #312

Closed
rjkroege opened this issue Sep 21, 2020 · 4 comments
Closed

MacOS: attaching to namespace forbidden #312

rjkroege opened this issue Sep 21, 2020 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@rjkroege
Copy link
Owner

Edwood is doing something wrong with names. I have tried to fix this with reattach-to-user-namespace but reliability is highly suspect.

@rjkroege
Copy link
Owner Author

On MacOS.

@rjkroege
Copy link
Owner Author

More details: on Catalina (occasionally) and now on Mac OS Big Sur, nothing can attach to Edwood's acme namespace. This breaks most interesting functionality (e.g. win, middle-clicking). p9p apps like plumber still successfully mount (and permit attach) via 9pserve. Conclusion: Edwood is doing something wrong with listening on socket connections. The exact error text is:

fsysmount: child: can't connect to acme: dial unix /tmp/ns.rjkroege.:0/acme: connect: connection refused

I had somewhat (naïvely?) assumed that this is related to the reattach-to-namespace... issues but this is not necessarily the case. (Note the differing situation with plumber.)

@rjkroege rjkroege self-assigned this Sep 21, 2020
@rjkroege rjkroege added bug Something isn't working in progress Work has started... labels Sep 21, 2020
@fhs
Copy link
Contributor

fhs commented Sep 22, 2020

Edwood uses 9pserver to listen to the socket, same as p9p acme. Does p9p acme work?

Edwood runs 9pserve -lv /tmp/ns.rjkroege.:0/acme and speaks 9p via its stdin/stdout. The -l flag means it'll write to the log file /tmp/ns.rjkroege.:0/acme.log. What's in the log file?

@rjkroege
Copy link
Owner Author

Thanks for the pointer. 9pserve is crashing. It does so similarly for Acme. (It works for plumb though so I had initially discounted it.)

Sep 22 05:48:17.491 incoming call on /dev/fd/4
thread stack overflow: &t=700006fd8f58 tstk=7fbea0008000 n=256

Experiments

  • Building with fhs/mux with go build -tags mux9p significantly improves Edwood operation but win still fails.

  • I upgraded p9p to the most recent version. Acme including win then worked as expected.

  • win also works with Edwood and the above linked p9p commit

  • win doesn't work with Edwood built with -tags mux9p but other features do. That seems like a lower-priority issue. I will create a different issue to track this.

  • I think libthread: use libc functions in ucontext for macOS is probably the most significant p9p change based on thread stack overflow

Summary

I deem this fixed enough to close this.

@rjkroege rjkroege removed the in progress Work has started... label Sep 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants