Skip to content

0.23.6 container dawarich_app is unhealthy #814

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

Closed
reichi62 opened this issue Feb 7, 2025 · 12 comments
Closed

0.23.6 container dawarich_app is unhealthy #814

reichi62 opened this issue Feb 7, 2025 · 12 comments

Comments

@reichi62
Copy link

reichi62 commented Feb 7, 2025

OS & Hardware
Host: raspi4 Kernel: 6.6.62+rpt-rpi-v8 arch: aarch64 bits: 64 Console: pty pts/0 Distro: Debian GNU/Linux 12 (bookworm)

Version
0.23.6

Describe the bug
The Container dawarich_app does not start properly. See section screenshot.

Expected behavior
The Container dawarich_app should start like before.

Screenshots

docker compose up -d
[+] Running 7/7
 ✔ Network dawarich_dawarich                                                                                                   Created                                                                                                                                1.7s 
 ✔ Container dawarich_redis                                                                                                    Healthy                                                                                                                                8.6s 
 ✔ Container dawarich_db                                                                                                       Healthy                                                                                                                                8.6s 
 ✘ Container dawarich_app                                                                                                      Error                                                                                                                                 49.6s 
 ! dawarich_app Your kernel does not support memory limit capabilities or the cgroup is not mounted. Limitation discarded.                                                                                                                                            0.0s 
 ✔ Container dawarich_sidekiq                                                                                                  Created                                                                                                                                0.2s 
 ! dawarich_sidekiq Your kernel does not support memory limit capabilities or the cgroup is not mounted. Limitation discarded.                                                                                                                                        0.0s 
dependency failed to start: container dawarich_app is unhealthy

Logs
dawarich_app | Caused by:
dawarich_app | PG::UndefinedFile: ERROR: could not open extension control file "/usr/local/share/postgresql/extension/postgis.control": No such file or directory (PG::UndefinedFile)

Comments
I had the version 0.23.5 up and running without issues.

@Freika
Copy link
Owner

Freika commented Feb 7, 2025

Please read release notes to 0.23.6 and this issue: #811

@Freika Freika closed this as completed Feb 7, 2025
@reichi62
Copy link
Author

reichi62 commented Feb 7, 2025

@Freika : thanks, this helped almost. I changed dockerCompos.yml.
But I have the problem with the postgis image for the Raspberry:
dawarich_db The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
I tried postgis/postgis:17-3.5-alpine and postgis/postgis:17-3.5⁠
I couldn't find an image for arm64.

@Freika
Copy link
Owner

Freika commented Feb 7, 2025

@reichi62 have you tried ghcr.io/baosystems/postgis:17-3.5 as suggested in the release notes?

@RobinFrcd
Copy link

Hi,
Yep, it indeed doesn't work on the raspberry without using any platform conversion:

$ docker pull ghcr.io/baosystems/postgis:17-3.5
17-3.5: Pulling from baosystems/postgis
no matching manifest for linux/arm/v8 in the manifest list entries

I guess I will roll back and monitor the status of postgis/docker-postgis#216 for now !

@Freika
Copy link
Owner

Freika commented Feb 8, 2025

@RobinFrcd can you try building your own image? Theoretically it should work: you can take these files: https://github.com/postgis/docker-postgis/tree/master/17-3.5/alpine

And then build an image with the following command: docker build --platform linux/arm64 -t local-postgis:latest .. Then in your dockerfile provide local-postgis as the database image name. Please let me know if it works

@RobinFrcd
Copy link

RobinFrcd commented Feb 8, 2025

Thanks for the quick answer ! Sadly, the build fails with:

--------------------
  13 |
  14 | >>> RUN apt-get update \
  15 | >>>       && apt-cache showpkg postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR \
  16 | >>>       && apt-get install -y --no-install-recommends \
  17 | >>>            # ca-certificates: for accessing remote raster files;
  18 | >>>            #   fix: https://github.com/postgis/docker-postgis/issues/307
  19 | >>>            ca-certificates \
  20 | >>>            \
  21 | >>>            postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR=$POSTGIS_VERSION \
  22 | >>>            postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR-scripts \
  23 | >>>       && rm -rf /var/lib/apt/lists/*
  24 |
--------------------
ERROR: failed to solve: process "/bin/sh -c apt-get update       && apt-cache showpkg postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR       && apt-get install -y --no-install-recommends            ca-certificates                       postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR=$POSTGIS_VERSION            postgresql-$PG_MAJOR-postgis-$POSTGIS_MAJOR-scripts       && rm -rf /var/lib/apt/lists/*" did not complete successfully: exit code: 159

Will try to dig into that when I have more time, but for now the 0.23.5 works super fine for me !

And

    image: ghcr.io/baosystems/postgis:17-3.5
    platform: linux/amd64

doesn't work either.

Thanks !

@Freika
Copy link
Owner

Freika commented Feb 8, 2025

@RobinFrcd and same for docker buildx build --platform linux/arm64 -t local-postgis:latest .?

@reichi62
Copy link
Author

reichi62 commented Feb 9, 2025

@Freika I could successfully build the image based on the files from https://github.com/postgis/docker-postgis/tree/master/17-3.5/alpine with command docker build --platform linux/arm64 -t local-postgis:latest .. After that I changed docker-compose.yml in this way:

dawarich_db:
    image: local-postgis:latest
    shm_size: 1G
    container_name: dawarich_db
    volumes:
      - dawarich_db_data:/var/lib/postgresql/data
      - dawarich_shared:/var/shared
      # - ./postgresql.conf:/etc/postgresql/postgresql.conf # Optional, uncomment if you want to use a custom config
    networks:
      - dawarich
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: my-password
    restart: always
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U postgres -d dawarich_development" ]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

When I run docker compose up -d I get this error:

PostgreSQL Database directory appears to contain a database; Skipping initialization
2025-02-09 06:52:57.256 UTC [1] FATAL:  database files are incompatible with server
2025-02-09 06:52:57.256 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 14, which is not compatible with this version 17.2.

To me, it sounds like the database conversion from v14 to v17 did not work. But I have insufficiont knowledge about this.

@Freika
Copy link
Owner

Freika commented Feb 9, 2025

@reichi62 hmmm, can you try with postgis 14 then?

@reichi62
Copy link
Author

reichi62 commented Feb 9, 2025

@Freika Success! With postgis 14 image I could start the services. This time I started each service seperately:

docker compose up -d dawarich_redis
docker compose up -d dawarich_db
docker compose up -d dawarich_app
docker compose up -d dawarich_sidekiq

I really checked that the service was ready and healthy with docker compose logs -f <service-name> before I started the next one.
Maybe this made the difference?! I'm going to try postgis 17 again later, when I have more time.
But what I do not understand is that I fully lost the content of the database. Actually the data is stored in the volume dawarich_db_data, isn't it? Maybe I did something wrong. But no worry, I used DaWarIch since a couple of days only, so the damage is not much high.

@RobinFrcd
Copy link

@reichi62 Would you mind sharing docker information on your system ?

$ docker system info
Client: Docker Engine - Community
 Version:    27.4.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.19.3
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.1
    Path:     /home/user/.docker/cli-plugins/docker-compose

Server:
 Containers: 9
  Running: 9
  Paused: 0
  Stopped: 0
 Images: 13
 Server Version: 27.4.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 88bf19b2105c8b17560993bee28a01ddc2f97182
 runc version: v1.2.2-0-g7cb3632
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.21-v8+
 Operating System: Raspbian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 7.629GiB
 Name: raspberrypi
 ID: 7802d023-7ab7-4d56-b78a-90839e325d59
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

@reichi62
Copy link
Author

reichi62 commented Feb 9, 2025

@RobinFrcd
Sure. Here it is:

$ docker system info
Client: Docker Engine - Community
 Version:    27.5.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.20.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.4
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 11
  Running: 11
  Paused: 0
  Stopped: 0
 Images: 24
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc version: v1.2.4-0-g6c52b3f
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.6.62+rpt-rpi-v8
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 7.627GiB
 Name: raspi4
 ID: dfb777bd-ebb3-4674-b964-d615f2470a36
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants