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