dgoss doesn't work on MacOS because of private `/tmp`
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
This seems like a duplicate of #329.
Also, I wonder if it's related to the following:
- https://stackoverflow.com/questions/37673140/docker-volume-located-in-tmp-on-osx-empty
- https://stackoverflow.com/questions/55667800/mac-docker-volume-mount-using-osxfs-not-working
I wonder if there's a way for dgoss to detect this.
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!
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.
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!