Guten Abend,
seit längerem habe ich auf einem Raspberry Pi eine PostgreSQL via Docker-Compose laufen. Da ist eine kleine Testdatenbank drauf, die ein paar Messwerte sammelt. Verwendet wurde der Tag postgres:12-alpine mit Version 12.3 zum Installationszeitpunkt. Nun wollte ich das ganze finalisieren und dementsprechend aktualisieren. Also habe ich das 12er Alpine Image gepullt und dadurch Version 12.6 erhalten. Seit diesem Update startet die Datenbank nicht mehr. Weder mit v12.3 noch 12.6. Ob Alpine oder Debian als Basis-Image genutzt wird spielt auch keine Rolle, es bleibt bei folgendem Fehler:

Code:
postgres_1  | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1  |
postgres_1  | 2021-03-31 17:00:05.213 UTC [1] LOG:  starting PostgreSQL 12.3 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 9.3.0) 9.3.0, 32-bit
postgres_1  | 2021-03-31 17:00:05.214 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres_1  | 2021-03-31 17:00:05.214 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres_1  | 2021-03-31 17:00:05.226 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1  | 2021-03-31 17:00:11.083 UTC [1] LOG:  startup process (PID 20) was terminated by signal 11: Segmentation fault
postgres_1  | 2021-03-31 17:00:11.084 UTC [1] LOG:  aborting startup due to startup process failure
postgres_1  | 2021-03-31 17:00:14.480 UTC [1] LOG:  database system is shut down
postgres_1 exited with code 1
Laut meinen Rerchen hängt es wohl mit dem Update von time_t zusammen. Dort hat man von 32 Bit auf 64 Bit aktualisiert, um einem Überlauf im Jahr 2038 vorzubeugen. Alpine Linux hat dies in Version 3.13.0 eingeführt, veröffentlicht am 14.01.2021.

Laut den Releasenotes gibt es zwei Anforderungen:

  • Docker-Version auf dem Host >= 19.03.9
  • libseccomp auf dem Host >= 2.4.2


Auf meinem RPI ist Docker 19.03.13 installiert. Die Bibliothek libseccomp2:armhf war wie beschrieben aus den stabilen Raspbian Repos in Version 2.3.3-4, also ohne den Fix. Daher habe ich händisch zunächst 2.5.1-1 und als das nicht funktionierte 2.4.4-1 installiert. Testweise auch den unsichereren Workaround, den Container zu privilegieren und seccomp mit "unconfined" komplett zu deaktivieren.

Damit habe ich es zwar geschafft, eine leere Datenbank (= neues Daten-Volume) erstellen zu können. Aber nicht meine bestehende Datenbank wieder zu starten. Sind keine weltbewegenden Daten drin. Ich würde das dennoch gerne fixen, da es mein erstes PostgreSQL Projekt ist und ich im Falle einer produktiven DB an der Stelle ungerne bloß das letzte Backup einspielen möchte...

Langsam gehen mir die Ideen aus, hat jemand noch welche oder das bestenfalls vielleicht sogar schon gemacht?

Die docker-compose.yml:

Code:
version: '2.4'
volumes:
  postgres-data:

services:
  postgres:
    image: postgres:12.6
    #image: postgres:12.3-alpine
    #image: postgres:12-alpine
    restart: always
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./create-tables.sql:/docker-entrypoint-initdb.d/create-tables.sql
    environment:
      POSTGRES_PASSWORD: xx
      POSTGRES_DB: xxx
    privileged: true
    cap_add:
      - sys_admin
    security_opt:
      - seccomp:unconfined
    ports:
      - 5432:5432