paperless-ngx: nach Update von portainer und paperless redis: "Error: Error -5 connecting to broker:6379. No address associated with hostname.."

[Maddm]

Hallo, ich bin neu hier im Forum und habe mich angemeldet, da ich ein Problem habe:
ich habe vor einiger Zeit auf meinem NAS (DSM224+) mit dieser Anleitung (klick) ein paperless-ngx installiert (incl. Container Manager als "Basis" für die Images).
Das Ganze lief soweit sehr ordentlich, ich hab dann kurze Zeit danach auch noch einen Container für iobroker dazugepackt, das hat alles gut geklappt.

Im Portainer habe ich heute morgen gesehen, dass es eine deutlich neuere Version von portainer gibt (ich hatte 2.2.1 installiert, die neueste Version ist die 2.2.7). Also habe ich gesucht, wie man das Update macht und das war hier gut erklärt - auch das hat funktioniert.
Dabei hatte ich im Container Manager gesehen, dass auch die Images für iobroker als auch für redis (wird für paperless gebraucht, ich weiß aber nicht genau wofür ) nicht aktuell waren - also habe ich bei beiden ebenfalls die Images aktualisiert, auch das hat augenscheinlich geklappt...

Als ich dann neue Dokumente in paperless hochladen wollte, kam nach dem Einlesen der Dokumente eine http 500er Fehlermeldung innerhalb von paperless, alle Bestandsdokumente waren aber noch vorhanden, aber die "Vorschau" der Dokumente war nicht zu sehen.

Ich habe dann das NAS einmal durchgebootet und habe jetzt nach dem Start das Problem, dass von den 3 Containern, die für paperless gebraucht werden, einer nicht hochfährt, sondern mit einer Fehlermeldung das Log beschreibt. Die Meldung des paperless-ngx containers im Log lautet wie folgt:

Paperless-ngx docker container starting...
Creating directory scratch directory /tmp/paperless
Adjusting permissions of paperless files. This may take a while.
Waiting for PostgreSQL to start...
Connected to PostgreSQL
Waiting for Redis...
Redis ping #0 failed.
Error: Error -5 connecting to broker:6379. No address associated with hostname..
Waiting 5s
Redis ping #1 failed.
Error: Error -5 connecting to broker:6379. No address associated with hostname..
Waiting 5s
Redis ping #2 failed.
Error: Error -5 connecting to broker:6379. No address associated with hostname..
Waiting 5s
Redis ping #3 failed.
Error: Error -5 connecting to broker:6379. No address associated with hostname..
Waiting 5s
Redis ping #4 failed.

Und jetzt muss ich zugeben, dass ich mit meinem mehr als geringen Wissen über Docker/Portainer und Co. am Ende bin und nicht weiß, was ich selbst tun muss, damit ich das Ganze wieder ans Laufen bringe.

Es wäre super, wenn jemand der hier deutlich tiefer drin steckt als ich in der Lage ist, den Fehler zu verstehen und mir Unterstützung geben kann, wie ich die Sache wieder lauffähig machen kann.

Falls ich weitere Infos etc. liefern muss, sagt mir einfach was ihr braucht (und evtl. auch wie ich die Infos erstelle).
Danke sehr

 

[haydibe]

Der IOBroker service hiess vorher "broker" und heisst jetzt "iobroker". Da dieser Name für die DNS-Namensauflösung verwendet wird, wird der Broker unter seinem neuen Namen nicht gefunden.

Einfachste Lösung: Service wieder so nennen wie er vorher hiess.

Update: vorher hat der broker service Redis verwendet. Der iobroker verwendet hier aber IoBrocker.
Wie kommt den der Wechsel von Redis zu IoBroker zustande?

Update2: ich sehe jetzt erst das der "broker" service den container namen "Paperless-NGX-REDIS" hat. Es muss sich (wie zuerst gedacht) der Servicename vom broker geändert haben. Aber was macht der iobroker hier in dem Scenario? Davon ist in der orginal Anleitung nichts zu finden.

Teil doch mal den Inhalt der compose Datei (müsste bei Portainer stacks heissen)

 

[Maddm]

@haydibe
Ok, schau mal ob das das ist, was ich liefern soll (bin über Portainer > Environment > Stack > paperless-ngx > Editor gegangen)

Weil du gefragt hast: für mich war paperless-ngx der Einstieg in "Container auf dem NAS" und weil das so gut lief, habe ich - unabhängig von paperless - auf eine iobroker Instanz in einem Container installiert.

services:
  broker:
    image: redis
    container_name: Paperless-NGX-REDIS
    restart: always
    volumes:
      - /volume1/docker/paperlessngx/redis:/data

  db:
    image: postgres:16
    container_name: Paperless-NGX-DB
    restart: always
    volumes:
      - /volume1/docker/paperlessngx/db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless

  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    container_name: Paperless-NGX
    restart: always
    depends_on:
      - db
      - broker
    ports:
      - 8777:8000
    volumes:
      - /volume1/docker/paperlessngx/data:/usr/src/paperless/data
      - /volume1/docker/paperlessngx/media:/usr/src/paperless/media
      - /volume1/docker/paperlessngx/export:/usr/src/paperless/export
      - /volume1/docker/paperlessngx/consume:/usr/src/paperless/consume
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: db
      USERMAP_UID: 1026
      USERMAP_GID: 100
      PAPERLESS_TIME_ZONE: Europe/Berlin
      PAPERLESS_ADMIN_USER: user_enfernt
      PAPERLESS_ADMIN_PASSWORD: pw_entfernt
      PAPERLESS_OCR_LANGUAGE: deu+eng

 

[haydibe]

Der Stack sieht gut aus: der Service-Name ist unverändert. Damit sollte es eigentlich funkionieren, ausser der "Paperless-NGX-REDIS" Container ist nicht richtige hochgekommen.

Allerdings kann es nicht richtig sein, einzelne Container eines Portainer Stacks (in Docker Compose übrigens ein "Project" und kein "Stack") zu aktuallisieren. Ich nutzte Portainer nicht, aber in Compose würde man klassich die neuen Images pullen und dann das Compose Project neu deployen, oder bei Image direkt die aktualliserten Tags eintragen, dann muss man vorher auch nicht die Images extra pullen.

 

[Maddm]

Ok, kann ich das jetzt noch irgendwie "retten" - also: mit dem Abschicken eines Kommandos oder ähnlich den Deploy nochmal machen so dass danach wieder alles geht?

 

[haydibe]

Ich würde es erstmal neu deployen (keine ahnung wie man das in Portainer macht).
Wenn es dann immer noch nicht geht, im redis container schauen ob in den Logs fehler sind.

Was mir gerade noch einfällt: das Tag der Postgres-Datenkbank auf eine Major Version zu pinnen, ist imho Risiko behaftet, da die Daten selbst beim welchsel einer Minor-Version (also 16.x auf 16.x+y) gedumped und neu eingespielt werden müssen. Keine Ahnung, ob es heutzutage immer noch so ist, aber das war zumindest das verhalten der letzten Jahre bei Postgres.

 

[Maddm]

Ok, damit ich hier noch eine Rückmeldung abliefere:
ich habe den kompletten Stack neu deployed und jetzt geht das Ganze wieder. Erfreulicherweise sind weder Daten noch Einstellungen dabei drauf gegangen, das ist sehr schön.
Danke für die Hilfe