Tandoor mittels Container Manager - nicht erreichbar

[toeoe]

Hallo zusammen

Ich hatte früher schon Tandoor auf meiner DS218+ installiert. Nach einem Update kam immer der Fehler 502.
Ich habe nun eine Neuinstallation vorgenommen (Container Manager zuerst geleert und deinstalliert, dann neu installiert). Ich bin bei der Neuinstallation gemäss https://docs.tandoor.dev/install/synology/ vorgegangen.
Das Projekt innerhalb des Container Managers kann gestartet werden, es gibt dort keine Fehler.
Ich kann aber Tandoor nicht erreichen über http://192.168.1.3:4080, wie ich das erwarten würde.
Edge meldet: "Diese Seite funktioniert im Moment nicht. 192.168.1.3 hat keine Daten gesendet."
Firefox meldet: "Fehler: Verbindung unterbrochen. Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde."
Was könnte hier das Problem sein? Reste der vorherigen Installation? Wo?

Ich bin dankbar für Tipps!

Ich habe die folgende ".env" verwendet:

# random secret key, use for example `base64 /dev/urandom | head -c50` to generate one
SECRET_KEY=[hier weggelassen]

# your default timezone See https://timezonedb.com/time-zones for a list of timezones
TZ=Europe/Berlin

# allowed hosts (see documentation), should be set to your hostname(s) but might be * (default) for some proxies/providers
ALLOWED_HOSTS=*

# add only a database password if you want to run with the default postgres, otherwise change settings accordingly
DB_ENGINE=django.db.backends.postgresql
POSTGRES_HOST=db_recipes
POSTGRES_DB=djangodb
POSTGRES_PORT=5432
POSTGRES_USER=djangouser
POSTGRES_PASSWORD=[hier weggelassen]

Die YAML-Konfiguration ist wie folgt:

services:
db_recipes:
restart: always
image: postgres:16-alpine
volumes:
- ./postgresql:/var/lib/postgresql/data
env_file:
- ./.env
web_recipes:
restart: always
image: vabene1111/recipes
env_file:
- ./.env
volumes:
- staticfiles:/opt/recipes/staticfiles
- ./mediafiles:/opt/recipes/mediafiles
depends_on:
- db_recipes
ports:
- "4080:8080"
volumes:
staticfiles:

 

[JohneDoe]

Guck mal in die Container Logs. So kann man dir nicht wirklich helfen.

 

[toeoe]

Danke für den Hinweis.

Im Log zu db_recipes-1 steht:

2025/10/15 16:39:28	stderr	2025-10-15 16:39:28.837 CEST [27] LOG: checkpoint complete: wrote 12 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.956 s, sync=0.379 s, total=2.268 s; sync files=5, longest=0.112 s, average=0.076 s; distance=7 kB, estimate=7 kB; lsn=0/1D88438, redo lsn=0/1D88400
2025/10/15 16:39:26	stderr	2025-10-15 16:39:26.569 CEST [27] LOG: checkpoint starting: time
2025/10/15 16:34:27	stderr	2025-10-15 16:34:27.253 CEST [1] LOG: database system is ready to accept connections
2025/10/15 16:34:26	stderr	2025-10-15 16:34:26.486 CEST [29] LOG: database system was shut down at 2025-10-15 16:33:14 CEST
2025/10/15 16:34:26	stderr	2025-10-15 16:34:26.225 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025/10/15 16:34:25	stderr	2025-10-15 16:34:25.455 CEST [1] LOG: listening on IPv6 address "::", port 5432
2025/10/15 16:34:25	stderr	2025-10-15 16:34:25.455 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2025/10/15 16:34:25	stderr	2025-10-15 16:34:25.455 CEST [1] LOG: starting PostgreSQL 16.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit
2025/10/15 16:34:22	stdout
2025/10/15 16:34:22	stdout	PostgreSQL Database directory appears to contain a database; Skipping initialization

Im Log zu web_recipes-1 steht:

date	stream	content
2025/10/15 16:35:22	stdout	Running django-vite in production mode (no HMR)
2025/10/15 16:35:21	stdout	Running django-vite in production mode (no HMR)
2025/10/15 16:35:21	stdout	Running django-vite in production mode (no HMR)
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [29] [INFO] Booting worker with pid: 29
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [28] [INFO] Booting worker with pid: 28
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [27] [INFO] Booting worker with pid: 27
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [7] [INFO] Using worker: gthread
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [7] [INFO] Listening at: unix:/run/tandoor.sock (7)
2025/10/15 16:35:21	stderr	[2025-10-15 16:35:21 +0200] [7] [INFO] Starting gunicorn 23.0.0
2025/10/15 16:35:20	stdout	Starting gunicorn
2025/10/15 16:35:20	stdout	Done
2025/10/15 16:35:20	stdout	788 static files copied to '/opt/recipes/staticfiles', 2150 post-processed.
2025/10/15 16:35:20	stdout
2025/10/15 16:35:08	stdout	Deleting 'treebeard/treebeard-admin.css.gz'
		viele weitere "Deleting"-Zeilen gelöscht
2025/10/15 16:35:06	stdout	Deleting 'admin/css/autocomplete.css'
2025/10/15 16:35:06	stdout	Deleting 'staticfiles.json'
2025/10/15 16:35:04	stdout	Running django-vite in production mode (no HMR)
2025/10/15 16:35:03	stdout	Collecting static files, this may take a while...
2025/10/15 16:35:01	stdout	No migrations to apply.
2025/10/15 16:35:01	stdout	Running migrations:
2025/10/15 16:35:00	stdout	Apply all migrations: account, admin, auth, authtoken, contenttypes, cookbook, mfa, oauth2_provider, sessions, sites, socialaccount, usersessions
2025/10/15 16:35:00	stdout	Operations to perform:
2025/10/15 16:34:35	stdout	Running django-vite in production mode (no HMR)
2025/10/15 16:34:32	stdout	Migrating database
2025/10/15 16:34:32	stdout	Database is ready
2025/10/15 16:34:32	stdout	Waiting for database to be ready...
2025/10/15 16:34:32	stdout	Checking configuration...
2025/10/15 16:34:31	stdout	Starting nginx

Hilft das zur Analyse?

 

[JohneDoe]

Das sieht auf den ersten Blick alles gut aus. Zeig mal wie du es konfiguriert hast.

 

[toeoe]

Danke für die Rückmeldung.
Was meinst du mit "konfiguriert"? Ich bin der Anleitung von https://docs.tandoor.dev/install/synology/ gefolgt (ohne SSL Setup).

 

[JohneDoe]

Ja, aber da du ja wahrscheinlich Anpassungen gemacht hast, bringt es nichts wenn ich eine Compose sehe die du so aber gar nicht nutzt. Weil sonst würde es ja funktionieren.

 

[RaZi]

Ich habe zwar keine Ahnung von Containern und so ...
Aber mit kommt der Eintrag

2025/10/15 16:34:25

stderr

2025-10-15 16:34:25.455 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432

suspekt vor. Denn 0.0.0.0 ist doch die IP v4 Subnet-Adresse. Soll das richtig sein?

 

[JohneDoe]

Das 0.0.0.0 ist schon ok so. Das heißt, dass er auf allen IPs lauscht die das Gerät hat. Wenn da z.B. 127.0.0.1 stehen würde, dann könntest du es nur über den Lokalhost erreichen. Oder bei 2 NICs und nur einer IpP Angabe, wär es nur über die eine IP erreichbar....

 

[toeoe]

Ja, aber da du ja wahrscheinlich Anpassungen gemacht hast, bringt es nichts wenn ich eine Compose sehe die du so aber gar nicht nutzt. Weil sonst würde es ja funktionieren.

Die Anpassungen, welche ich gemacht habe, sind im 1. Post zu sehen (.env und YAML-Konfiguration).
Dazu habe ich eine Einstellung in der Firewall gemacht, dass alles von 172.19.0.0/255.255.255.0 zugelassen wird und dass alle Quell-IP auf den Port 4080 zugreifen dürfen.
Weiter habe ich am Router eine Portweiterleitung für 4080 (TCP) auf die Synology Box gemacht.
Müsste ich weitere Anpassungen machen?

 

[JohneDoe]

Sorry die Compose habe ich in Post 1 nicht gesehen...
Solange das nicht funktioniert würde ich den Port nicht weiterleiten.
Hast du es mal ohne Firewall probiert? So kann ich gerade nichts sehen was der Grund sein könnte.

 

[toeoe]

Danke für deinen Tipp. Ich habe soeben die Firewall deaktiviert, gleiches Problem.
Ich befürchte, dass noch Altlasten der vorherigen Installation vorhanden sind. Was muss ich tun, um komplett aufzuräumen? Container-Manager deinstallieren, neustarten, Docker-Verzeichnis löschen? Oder ist die postgres-Datenbank noch irgendwo anders verhakt?

 

[JohneDoe]

Die Ordner die du angelegt hast löschen oder einfach einen anderen Ordner nutzen. Du hast ja relative Pfade. Das Volumen staticfiles noch löschen. Das ist ein Docker Volume. Musst mal gucken ob der Container Manager das irgendwo kann. Ich verwende den nicht und weiß es daher nicht.

 

[toeoe]

Ich konnte bei der Neuinstallation über einen Docker-Befehl via SSH sicherstellen, dass auch das Volume staticfiles nicht mehr existierte. Nach der Neuinstallation das gleiche Bild.
Vielleicht von Bedeutung: In Firefox wird auf dem Tandoor-Port 4080 "Fehler: Verbindung unterbrochen" gemeldet, auf einem beliebigen Port wie 2000 hingegen "Verbindung fehlgeschlagen".

 

[JohneDoe]

Probier mal per SSH folgenden Befehl aus:
curl http://localhost:4080

 

[toeoe]

Vielleicht noch als Ergänzung das Log des Containers db_recipes direkt nach der Neuinstallation:

date	stream	content
2025/10/19 10:47:41	stderr	2025-10-19 10:47:41.600 CEST [54] LOG: checkpoint starting: time
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.599 CEST [1] LOG: database system is ready to accept connections
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.501 CEST [56] LOG: database system was shut down at 2025-10-19 10:42:40 CEST
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.343 CEST [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.162 CEST [1] LOG: listening on IPv6 address "::", port 5432
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.162 CEST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2025/10/19 10:42:41	stderr	2025-10-19 10:42:41.162 CEST [1] LOG: starting PostgreSQL 16.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit
2025/10/19 10:42:40	stdout
2025/10/19 10:42:40	stdout	PostgreSQL init process complete; ready for start up.
2025/10/19 10:42:40	stdout
2025/10/19 10:42:40	stdout	server stopped
2025/10/19 10:42:40	stdout	done
2025/10/19 10:42:40	stdout	2025-10-19 10:42:40.142 CEST [40] LOG: database system is shut down
2025/10/19 10:42:40	stdout	...........................2025-10-19 10:42:40.132 CEST [41] LOG: checkpoint complete: wrote 926 buffers (5.7%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.379 s, sync=26.154 s, total=27.428 s; sync files=301, longest=0.426 s, average=0.087 s; distance=4272 kB, estimate=4272 kB; lsn=0/191E928, redo lsn=0/191E928
2025/10/19 10:42:12	stdout	2025-10-19 10:42:12.874 CEST [41] LOG: checkpoint starting: shutdown immediate
2025/10/19 10:42:12	stdout	2025-10-19 10:42:12.704 CEST [41] LOG: shutting down
2025/10/19 10:42:12	stdout	2025-10-19 10:42:12.702 CEST [40] LOG: background worker "logical replication launcher" (PID 46) exited with exit code 1
2025/10/19 10:42:12	stdout	waiting for server to shut down....2025-10-19 10:42:12.688 CEST [40] LOG: aborting any active transactions
2025/10/19 10:42:12	stdout	2025-10-19 10:42:12.474 CEST [40] LOG: received fast shutdown request
2025/10/19 10:42:12	stdout
2025/10/19 10:42:12	stdout	/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2025/10/19 10:42:12	stdout
2025/10/19 10:42:12	stdout
2025/10/19 10:42:12	stdout	CREATE DATABASE
2025/10/19 10:42:07	stdout	server started
2025/10/19 10:42:07	stdout	done
2025/10/19 10:42:07	stdout	.2025-10-19 10:42:07.814 CEST [40] LOG: database system is ready to accept connections
2025/10/19 10:42:07	stdout	2025-10-19 10:42:07.510 CEST [43] LOG: database system was shut down at 2025-10-19 10:41:59 CEST
2025/10/19 10:42:06	stdout	..2025-10-19 10:42:06.991 CEST [40] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025/10/19 10:42:05	stdout	waiting for server to start....2025-10-19 10:42:05.488 CEST [40] LOG: starting PostgreSQL 16.10 on x86_64-pc-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit
2025/10/19 10:42:02	stdout
2025/10/19 10:42:02	stdout	pg_ctl -D /var/lib/postgresql/data -l logfile start
2025/10/19 10:42:02	stdout
2025/10/19 10:42:02	stdout	Success. You can now start the database server using:
2025/10/19 10:42:02	stdout
2025/10/19 10:42:02	stderr	initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
2025/10/19 10:42:02	stderr	initdb: warning: enabling "trust" authentication for local connections
2025/10/19 10:42:02	stdout
2025/10/19 10:42:02	stdout	syncing data to disk ... ok
2025/10/19 10:41:59	stdout	performing post-bootstrap initialization ... ok
2025/10/19 10:41:57	stderr	2025-10-19 10:41:57.066 CEST [34] WARNING: no usable system locales were found
2025/10/19 10:41:57	stderr	sh: locale: not found
2025/10/19 10:41:55	stdout	running bootstrap script ... ok
2025/10/19 10:41:54	stdout	creating configuration files ... ok
2025/10/19 10:41:54	stdout	selecting default time zone ... Europe/Berlin
2025/10/19 10:41:53	stdout	selecting default shared_buffers ... 128MB
2025/10/19 10:41:53	stdout	selecting default max_connections ... 100
2025/10/19 10:41:53	stdout	selecting dynamic shared memory implementation ... posix
2025/10/19 10:41:53	stdout	creating subdirectories ... ok
2025/10/19 10:41:53	stdout	fixing permissions on existing directory /var/lib/postgresql/data ... ok
2025/10/19 10:41:53	stdout
2025/10/19 10:41:53	stdout	Data page checksums are disabled.
2025/10/19 10:41:53	stdout
2025/10/19 10:41:53	stdout	The default text search configuration will be set to "english".
2025/10/19 10:41:53	stdout	The default database encoding has accordingly been set to "UTF8".
2025/10/19 10:41:53	stdout	The database cluster will be initialized with locale "en_US.utf8".
2025/10/19 10:41:53	stdout
2025/10/19 10:41:53	stdout	This user must also own the server process.
2025/10/19 10:41:53	stdout	The files belonging to this database system will be owned by user "postgres".

 

[toeoe]

Probier mal per SSH folgenden Befehl aus:
curl http://localhost:4080

curl: (56) Recv failure: Connection reset by peer

 

[toeoe]

Bei curl -v http://localhost:4080 erhalte ich:

> GET / HTTP/1.1
> Host: 192.168.1.3:4080
> User-Agent: curl/7.86.0
> Accept: */*
>
* Recv failure: Connection reset by peer
curl: (56) Recv failure: Connection reset by peer

 

[toeoe]

Es hat sich herausgestellt, dass es sich um einen Fehler beim Port handelte. Neuerdings muss es in der YAML-Konfiguration

ports:
- "4080:80"

statt

ports:
- "4080:8080"

heissen.