When deploying uMap using Docker Compose encounter a RuntimeError Version :2.5.1

[gguanilo]

Max post-process passes exceeded during the static file collection process. This error suggests a configuration or environment issue specific to Windows, as the same Docker configuration works flawlessly on a Windows machine.

To Reproduce Steps to reproduce the behavior:

Deploy uMap using the provided Docker Compose file on Windows. Access the application via http://myexample:9081/. Observe the error during the startup, specifically during the Django static file collection process. Expected behavior The application should start without errors, similar to the behavior observed on a Windows environment, allowing the uMap service to be accessible and functional.

Additional context This issue appears to be specific to the windows environment.

[davidbgk]

Looks related to #1947, thanks for narrowing it down to Synology with your additional tests 👍

[Pfaff15]

Sadly I encounter the same problems but not on Synology but on Ubuntu 24.04 LTS..

[rouja]

Hi,

@Pfaff15 what is the output of this command :

docker run -it --entrypoint /bin/bash umap/umap:2.5.1 -c "umap collectstatic --noinput"

[Pfaff15]

Hi @rouja

I ran your commant once for the working 2.3.1:

No valid UMAP_SETTINGS found

391 static files copied to '/srv/umap/static', 391 post-processed.

And once for the 2.5.1 with following output:

No valid UMAP_SETTINGS found Error with file All Traceback (most recent call last): File "/venv/bin/umap", line 8, in sys.exit(main()) ^^^^^^ File "/venv/lib/python3.11/site-packages/umap/bin/init.py", line 9, in main management.execute_from_command_line() File "/venv/lib/python3.11/site-packages/django/core/management/init.py", line 442, in execute_from_command_line utility.execute() File "/venv/lib/python3.11/site-packages/django/core/management/init.py", line 436, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/venv/lib/python3.11/site-packages/django/core/management/base.py", line 413, in run_from_argv self.execute(*args, *cmd_options) File "/venv/lib/python3.11/site-packages/django/core/management/base.py", line 459, in execute output = self.handle(args, **options) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/venv/lib/python3.11/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 209, in handle collected = self.collect() ^^^^^^^^^^^^^^ File "/venv/lib/python3.11/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 148, in collect for original_path, processed_path, processed in processor: File "/venv/lib/python3.11/site-packages/umap/storage.py", line 50, in post_process raise processed RuntimeError: Max post-process passes exceeded.

[rouja]

Hi @Pfaff15

It's weird. What is the output of this command :

docker run -it --entrypoint /bin/bash umap/umap:2.5.1 -c "apt update &> /dev/null && apt install procps -y &>/dev/null && sysctl -a"

And this command :

docker inspect umap/umap:2.5.1 |grep 7f31ddab12c54faf97e2e24e9d8643998fde6e7575a8388336f8b29981017aaf

Juste to be sure you have the same image. Because I'm on ubuntu 24.04 too and I do not have that issue.

And could you provide your docker version :

docker version

[Pfaff15]

Hi @rouja

The first command gives this output (for better readability in a seperate file):

output.txt

The second command gives:

"umap/umap@sha256:7f31ddab12c54faf97e2e24e9d8643998fde6e7575a8388336f8b29981017aaf"

Docker version delivers:

Client: Docker Engine - Community Version: 27.1.1 API version: 1.46 Go version: go1.21.12 Git commit: 6312585 Built: Tue Jul 23 19:57:14 2024 OS/Arch: linux/amd64 Context: default

Server: Docker Engine - Community Engine: Version: 27.1.1 API version: 1.46 (minimum version 1.24) Go version: go1.21.12 Git commit: cc13f95 Built: Tue Jul 23 19:57:14 2024 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.7.19 GitCommit: 2bf793ef6dc9a18e00cb12efb64355c2c9d5eb41 runc: Version: 1.7.19 GitCommit: v1.1.13-0-g58aa920 docker-init: Version: 0.19.0 GitCommit: de40ad0

My docker-compose.yaml for the working 2.3.1 looks like this, if it is relevant. The only difference would be the Tag 2.5.1 instead of 2.3.1:

services: db:

check https://hub.docker.com/r/postgis/postgis to see available versions

image: postgis/postgis:14-3.4-alpine
environment:
  - POSTGRES_HOST_AUTH_METHOD=trust
volumes:
  - umap_db:/var/lib/postgresql/data

app:

Check https://hub.docker.com/r/umap/umap/tags to find the latest version

image: umap/umap:2.3.1
ports:
  # modify the external port (8001, on the left) if desired, but make sure it matches SITE_URL, below
  - "8001:8000"
environment:
  - DATABASE_URL=postgis://postgres@db/postgres
  - SITE_URL=https://myip:8001/
  - STATIC_ROOT=/srv/umap/static
  - MEDIA_ROOT=/srv/umap/uploads
  - SECRET_KEY=994E4DDA63026623E831309A90DD0F46
  - ENABLE_ACCOUNT_LOGIN=1
volumes:
  - umap_userdata:/srv/umap/uploads
  # FIX the path on the left, below, to your location 
  # OPTIONAL, you can comment the line below out for default
  # values to apply
  #- ./config/umap.conf:/etc/umap/umap.conf
restart: unless-stopped
depends_on:
  - db

volumes: umap_userdata: umap_db:

[rouja]

Hi @Pfaff15

I do not understand :(

I was not using the same version of docker so I installed your version but I can't reproduce your issue :(

The only thing that I do not have is your "data".

Do you have the same issue if you use empty volumes ?

Yesterday a fix on the Dockerfile was published on master because the build was broken. It concerns static folder. I built an image with this fix to test it : lasuite/umap:2.5.1-5a0b75fd3322cf

Do you still have the issue with that image ?

[Pfaff15]

Hi @rouja

In this case we are already two that do not understand :D

When changing the version number I usually stopped the containers with docker compose down -v. In my understanding this should have deleted the volumes...

I now took the some docker-compose.yaml and just adjusted the image of the app. Interestingly, the containers seem to run. But now I get an error message when connecting with the browser:

When starting the container in the shell with docker compose up I get some error messages, all connected with the django path. Here some examples:

..... app-1 | File "/venv/lib/python3.11/site-packages/django/core/handlers/exception.py", line 55, in inner app-1 | response = get_response(request) app-1 | ^^^^^^^^^^^^^^^^^^^^^ app-1 | File "/venv/lib/python3.11/site-packages/django/core/handlers/base.py", line 220, in _get_response app-1 | response = response.render() app-1 | ^^^^^^^^^^^^^^^^^ app-1 | File "/venv/lib/python3.11/site-packages/django/template/response.py", line 114, in render app-1 | self.content = self.rendered_content app-1 | ^^^^^^^^^^^^^^^^^^^^^ .....

Before, the app-container just was in a reboot-loop and naturally not reachable via browser

As a test I also started with empty volumes and the new image. However, the result is the same: containers running, django errors and the Ooops in the browser

[rouja]

Ok,

Now I can reproduce your issue. With your last docker-compose.yml, if you add :

      - DEBUG=1

It should work and the "Oops page" disappears. I'm not a django expert but I think It's not normal to have to enable the DEBUG to make things work. @davidbgk do you have an idee why with DEBUG=1 everything is fine but with DEBUG=0 it's not working ?

[Pfaff15]

I can confirm that it now also works in my configuration. Thank you for your support :-)

However, I still do not understand, what the underlying problem in the first place was. But if the fix of the static folder fixes all, then I am more than happy.

[rouja]

Ok cool !

When we will publish another docker image, please do no forget to switch the docker image in your docker-compose.yml to the new one because I will delete the temporary image "lasuite/umap:2.5.1-5a0b75fd3322cf".

Have a nice day