Closed phillipjohnson closed 3 years ago
I'm surprised by the ModuleNotFoundError: No module named 'girder_large_image'
error. The id: ‘987’: no such user
error I could reproduce on a fresh CentOS machine, and have a fix for it in PR #150 (the number is the docker group id, which as stated, isn't a user). Can you try on that branch and see if it will start for you?
One difference is that I haven't tested running as root (it usually isn't recommended).
Thanks for the quick reply @manthey. Your PR looks to have fixed the user 987 error, I'm just getting this output now:
Adding user `root' to group `root' ...
Adding user root to group root
Done.
Adding group `docker' (GID 987) ...
Done.
Adding user `root' to group `docker' ...
Adding user root to group docker
Done.
Traceback (most recent call last):
File "/opt/digital_slide_archive/devops/dsa/provision.py", line 18, in <module>
from girder_large_image.models.image_item import ImageItem
ModuleNotFoundError: No module named 'girder_large_image'
The user `root' is already a member of `root'.
The user `root' is already a member of `docker'.
What's really strange to me is that this command works:
docker run -it --rm dsarchive/dsa_common su -c "PATH=\"/opt/digital_slide_archive/devops/dsa/utils:/opt/venv/bin:/.pyenv/bin:/.pyenv/shims:$PATH\"; python /opt/digital_slide_archive/devops/dsa/provision.py"
Running in mode: development
Connecting to MongoDB: mongodb://mongodb:27017/girder?socketTimeoutMS=3600000
I agree about not using root user, I was just trying to see about getting something set up for a demo. Definitely would create a special user if we choose to stand this up in a production capacity. I can also give that a shot if you think it's causing the module not found problem.
I just tried running as root. The only issue I see is that I get an error on the worker since celery won't run as root with the C_FORCE_ROOT
environment variable set.
Are you using a custom docker-compose.yml file? Did you build the docker image locally (if so, could you try to pull the built image)? Could you share the entire docker-compose logs girder
output?
I'll merge PR #150, as it is a strict improvement.
I'm using a slightly customized docker file (mount the image storage, port number, and C_FORCE_ROOT
):
It's you're extra mount: - /opt/dsa-images:/opt/large_image
. /opt/large_image
contains python modules including the girder_large_image
module. By mounting at that location, those modules are no longer available. You'll either want to use a different mount point or make sure the appropriate files also exist in the local /opt/dsa-images directory.
Ah, that's my fault for reading the file incorrectly, I thought you were supposed to mount to that point. Didn't realize you'd be able to define the asset stores once in the app. I've got it up and running now. Thank you for your help!
When trying to run DSA with the docker-compose file, the girder and worker containers repeat this block in the logs over and over:
When running this, it looks like the module is present
docker run -it --rm dsarchive/dsa_common pip list
, so perhaps that error is a red herring. I am not sure about the user 987, I'm running this asroot
.RHEL 7.9 Docker 20.10.6 Image is
dsarchive/dsa_common:latest