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

[BUG] Environment not set correctly when using docker exec #438

Closed
jacobtomlinson opened this issue Mar 17, 2022 · 2 comments
Closed

[BUG] Environment not set correctly when using docker exec #438

jacobtomlinson opened this issue Mar 17, 2022 · 2 comments
Labels
? - Needs Triage Need team to review and classify bug Something isn't working

Comments

@jacobtomlinson
Copy link
Member

jacobtomlinson commented Mar 17, 2022

Describe the bug
When using docker exec with inline bash commands the environment and path is not set correctly.

Steps/Code to reproduce bug

$ # Works
$ docker run -it --rm rapidsai/rapidsai-core:22.02-cuda11.5-runtime-ubuntu20.04-py3.8 /bin/bash -c "which dask-scheduler"
/opt/conda/envs/rapids/bin/dask-scheduler


$ # Works
$ docker run -it --rm rapidsai/rapidsai-core:22.02-cuda11.5-runtime-ubuntu20.04-py3.8 /bin/bash 
(rapids) root@cba78a78c0c4:/rapids/notebooks# which dask-scheduler
/opt/conda/envs/rapids/bin/dask-scheduler


$ # Works
$ docker run -d --name raptest rapidsai/rapidsai-core:22.02-cuda11.5-runtime-ubuntu20.04-py3.8
$ docker exec -it raptest /bin/bash
(rapids) root@079b262f3c0b:/rapids/notebooks# which dask-scheduler
/opt/conda/envs/rapids/bin/dask-scheduler
(rapids) root@079b262f3c0b:/rapids/notebooks# exit
$ docker rm -f raptest


$ # Doesn't work
$ docker run -d --name raptest rapidsai/rapidsai-core:22.02-cuda11.5-runtime-ubuntu20.04-py3.8
$ docker exec -it raptest /bin/bash -c "which dask-scheduler"

$ docker rm -f raptest

Additional context
The exec is being used by an external health check to ensure Dask is installed in the container. I need to be able to run a one-line exec that verifies that dask-scheduler can be called. I can work around by setting the external health check to use the full path, this means the health check is no longer portable to other images.

It seems that inline bash commands are not picking up the environment that is set by the entrypoint script. Perhaps a solution would be for things to be installed in the base environment, or for the rapids environment to be the default, without the entrypoint needing to be called.

@jacobtomlinson jacobtomlinson added ? - Needs Triage Need team to review and classify bug Something isn't working labels Mar 17, 2022
@ajschmidt8
Copy link
Member

Hey @jacobtomlinson. We'll look into this. We're currently exploring a lot of changes to our images that may potentially address this problem and the one described in #439. There is currently no ETA on this effort though.

@raydouglass
Copy link
Member

This is resolved by the overhaul: #539 & #545

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
? - Needs Triage Need team to review and classify bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants