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

dgoss doesn't work on MacOS because of private /tmp #624

Open
jay7x opened this issue Sep 30, 2020 · 4 comments
Open

dgoss doesn't work on MacOS because of private /tmp #624

jay7x opened this issue Sep 30, 2020 · 4 comments

Comments

@jay7x
Copy link
Contributor

jay7x commented Sep 30, 2020

Describe the bug
It seems dgoss doesn't work on MacOS because /tmp is private (I guess). I.e. docker cannot see files created by user.

How To Reproduce
Install current dgoss & goss on MacOS as described in documentation and try dgoss edit alpine sleep 1000 e.g. You may see there is no goss binary copied into container. See Actual Behavior for example.

Expected Behavior
It's expected to have /goss/goss binary in docker container.

➜  dgoss edit alpine sleep 1000
INFO: Starting docker container
INFO: Container ID: f1911630
INFO: Run goss add/autoadd to add resources
/goss # ls -la /goss/
total 8332
drwxrwxrwx    4 root     root           128 Sep 30 11:30 .
drwxr-xr-x    1 root     root          4096 Sep 30 11:30 ..
-rw-r--r--    1 root     root             0 Sep 30 11:30 docker_output.log
-rwxr-xr-x    1 root     root       8524064 Sep 30 11:30 goss

Actual Behavior

➜ dgoss edit alpine sleep 1000
INFO: Starting docker container
INFO: Container ID: 389e40a1
INFO: Run goss add/autoadd to add resources
/goss # ls -la /goss/
total 4
drwxr-xr-x    2 root     root            40 Sep 30 11:27 .
drwxr-xr-x    1 root     root          4096 Sep 30 11:27 ..

Environment:

  • goss version v0.3.6
  • MacOS Mojave 10.14.6 (18G6020)

How to fix
I fixed it for myself by applying the following change. Actually I'm just using ~/tmp instead of /tmp. I'm not sure it's good solution for everyone though.. I'd prefer to be able to override it via environment variable.

➜  diff -u dgoss.orig dgoss
--- dgoss.orig	2020-09-30 19:30:28.000000000 +0800
+++ dgoss	2020-09-30 19:30:37.000000000 +0800
@@ -66,7 +66,7 @@
 }

 # Main
-tmp_dir=$(mktemp -d /tmp/tmp.XXXXXXXXXX)
+tmp_dir=$(mktemp -d ~/tmp/tmp.XXXXXXXXXX)
 chmod 777 "$tmp_dir"
 trap 'ret=$?;cleanup;exit $ret' EXIT
@jay7x jay7x added the bug label Sep 30, 2020
@aelsabbahy
Copy link
Member

This seems like a duplicate of #329.

Also, I wonder if it's related to the following:

I wonder if there's a way for dgoss to detect this.

@jay7x
Copy link
Contributor Author

jay7x commented Oct 5, 2020

Ah, you're right! #329 is about the same issue. And from second link it seems the actual reason is not the private /tmp but how docker hyperkit VM is started. Well, that's explains.

You can close this then. #329 is enough and there is cp strategy which should work. Thank you!

@jay7x
Copy link
Contributor Author

jay7x commented Oct 5, 2020

Regarding way to detect.. You can try to check the goss presence (or execution result) with mount strategy and if there is no fallback to cp strategy.

@aelsabbahy
Copy link
Member

I'll keep this ticket open to implement the detection. I think it should error and fail and allow the user to decide to use cp, only because docker_output.log doesn't show up in cp mode, so it's not exactly the same user experience.

Thanks!

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

2 participants