Ich betreibe Discourse auf Debian 11 mit Docker als Einzelcontainer.
Ich habe versucht, es mit ./launcher rebuild app zu aktualisieren.
Es schlägt mit dieser Meldung fehl:
I, [2023-01-04T20:53:09.920876 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
rake aborted!
Ich finde keinen Weg, es wieder zum Laufen zu bringen.
Irgendwelche Ideen?
Ich sehe, dass der Besitzer falsch ist
drwxr-xr-x 15 sshd netdev 4096 Jan 4 21:43 .
drwxr-xr-x 3 root root 4096 Jan 3 2018 ..
drwxr-xr-x 3 1000 www-data 4096 Jan 3 2018 backups
drwxr-xr-x 8 sshd netdev 4096 Feb 2 2021 letsencrypt
drwxr-xr-x 4 sshd netdev 4096 Jan 3 2018 log
drwxr-xr-x 2 systemd-timesync systemd-resolve 4096 Jan 3 2018 postgres_backup
drwx------ 19 systemd-timesync systemd-resolve 4096 Jan 4 21:53 postgres_data
drwx------ 19 sshd netdev 4096 Jan 4 20:49 postgres_data_new
drwxrwsr-x 6 systemd-timesync systemd-resolve 4096 Jan 4 21:53 postgres_run
drwxr-xr-x 2 systemd-resolve kvm 4096 Jan 4 21:53 redis_data
drwxr-xr-x 2 sshd netdev 4096 Jan 22 2021 ssl
drwxr-xr-x 2 sshd netdev 4096 Jan 21 2021 ssl_old
drwxr-xr-x 4 sshd netdev 4096 Jan 3 2018 state
drwxr-xr-x 4 1000 www-data 4096 Jan 4 21:28 tmp
drwxr-xr-x 4 1000 www-data 4096 Jan 5 2018 uploads
Ich starte den Container mit ./launcher start app. Dann betrete ich den Container: ./launcher enter app.
Ich setze den Besitz zurück chown -R postgres:postgres /shared/
Danach ist es korrigiert. Aber wenn ich die App erneut baue, ist der Besitzer wieder falsch…
Das ist nicht der Fehler, er wird weiter oben liegen. Wir müssen mehr vom Log sehen.
2023-01-04 20:48:05.355 UTC [41] LOG: starting PostgreSQL 13.9 (Debian 13.9-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2023-01-04 20:48:05.377 UTC [41] LOG: listening on IPv4 address "0.0.0.0", port 5432
2023-01-04 20:48:05.377 UTC [41] LOG: listening on IPv6 address "::", port 5432
2023-01-04 20:48:05.566 UTC [41] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2023-01-04 20:48:05.734 UTC [44] LOG: database system was shut down at 2023-01-04 20:46:17 UTC
2023-01-04 20:48:05.878 UTC [41] LOG: database system is ready to accept connections
I, [2023-01-04T20:48:09.779985 #1] INFO -- :
I, [2023-01-04T20:48:09.780390 #1] INFO -- : > su postgres -c 'createdb discourse' || true
2023-01-04 20:48:10.014 UTC [54] postgres@postgres ERROR: database "discourse" already exists
2023-01-04 20:48:10.014 UTC [54] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: error: database creation failed: ERROR: database "discourse" already exists
I, [2023-01-04T20:48:10.017003 #1] INFO -- :
I, [2023-01-04T20:48:10.017425 #1] INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
2023-01-04 20:48:10.188 UTC [58] postgres@discourse ERROR: role "discourse" already exists
2023-01-04 20:48:10.188 UTC [58] postgres@discourse STATEMENT: create user discourse;
ERROR: role "discourse" already exists
129:M 04 Jan 2023 20:48:21.224 # Failed listening on port 6379 (TCP), aborting.
Ich sehe keine weiteren Fehler.
Innerhalb des Containers versuche ich, den Dienst postgresql zu starten und erhalte eine Fehlermeldung.
root@server /var/discourse # ./launcher enter app
x86_64 arch detected.
root@discourse:/var/www/discourse# service postgresql start
[FAIL] Starting PostgreSQL 13 database server: main[....] Error: Config owner (postgres:105) and data owner (systemd-timesync:101) do not match, and config owner is not root ... failed!
failed!
root@discourse:/var/www/discourse#
Wenn Sie die Besitzer der Dateien im freigegebenen Ordner geändert haben, wird die Installation unterbrochen. Eine Option ist die Neuinstallation und Wiederherstellung eines Backups, während die andere darin besteht, diese Besitzer manuell zu korrigieren.
@Falco: Danke!
Ich habe die Besitzer nach dem fehlgeschlagenen Upgrade geändert. Den Hinweis auf chown habe ich irgendwo in einem Beitrag gefunden.
Wie kann ich ein Backup im aktuellen Zustand erstellen?
Wie kann ich die Besitzer manuell reparieren?
Nochmal danke!
Innerhalb des Containers habe ich discourse backup versucht. Es wird berichtet, dass Redis nicht läuft. Im „aktuellen“ Redis-Log habe ich am Ende die folgenden Zeilen gefunden…
10316:M 05 Jan 2023 08:05:27.314 # Server initialisiert
10316:M 05 Jan 2023 08:05:27.314 # WARNUNG: overcommit_memory ist auf 0 gesetzt! Hintergrundspeicherung kann unter Bedingungen mit wenig Speicher fehlschlagen. Um dieses Problem zu beheben, fügen Sie 'vm.overcommit_memory = 1' zu /etc/sysctl.conf hinzu und starten Sie dann neu oder führen Sie den Befehl 'sysctl vm.overcommit_memory=1' aus, damit dies wirksam wird.
10316:M 05 Jan 2023 08:05:27.314 # Kann RDB-Formatversion 10 nicht verarbeiten
10316:M 05 Jan 2023 08:05:27.314 # Fataler Fehler beim Laden der DB: Ungültiges Argument. Beende.
10321:C 05 Jan 2023 08:05:28.345 # oO0OoO0OoO0Oo Redis startet oO0OoO0OoO0Oo
10321:C 05 Jan 2023 08:05:28.345 # Redis-Version=6.2.3, Bits=64, Commit=00000000, Geändert=0, PID=10321, gerade gestartet
10321:C 05 Jan 2023 08:05:28.345 # Konfiguration geladen
10321:M 05 Jan 2023 08:05:28.346 * Monotonische Uhr: POSIX clock_gettime
10321:M 05 Jan 2023 08:05:28.347 * Ausführungsmodus=standalone, Port=6379.
10321:M 05 Jan 2023 08:05:28.347 # WARNUNG: Die TCP-Backlog-Einstellung von 511 kann nicht erzwungen werden, da /proc/sys/net/core/somaxconn auf den niedrigeren Wert 128 gesetzt ist.
10321:M 05 Jan 2023 08:05:28.347 # Server initialisiert
10321:M 05 Jan 2023 08:05:28.347 # WARNUNG: overcommit_memory ist auf 0 gesetzt! Hintergrundspeicherung kann unter Bedingungen mit wenig Speicher fehlschlagen. Um dieses Problem zu beheben, fügen Sie 'vm.overcommit_memory = 1' zu /etc/sysctl.conf hinzu und starten Sie dann neu oder führen Sie den Befehl 'sysctl vm.overcommit_memory=1' aus, damit dies wirksam wird.
10321:M 05 Jan 2023 08:05:28.348 # Kann RDB-Formatversion 10 nicht verarbeiten
10321:M 05 Jan 2023 08:05:28.348 # Fataler Fehler beim Laden der DB: Ungültiges Argument. Beende.
Ich habe die Berechtigungen wie folgt korrigiert (innerhalb des Containers):
Danach habe ich den Container mit ./launcher restart app neu gestartet. Jetzt kann ich auf Discourse zugreifen. Aber es ist die alte Version 2.8.3, auf die ich gestern versucht habe, auf 3.0.0.beta16 zu aktualisieren.
Ich bin mir nicht sicher, wie ich mit dem Upgrade von Discourse fortfahren soll.
Ich glaube, mein Problem hängt mit diesem Thread zusammen: Problem upgrading multi-site/multi-containers Discourse instance - #5 by jtraulle
Ich erinnere mich, dass ich schon früher Probleme beim Upgrade hatte, aber sie nie untersucht habe.
./launcher rebuild app
Ich konnte die Version auf 2.9.0.beta2 (Commit-ID: 88a8584348ed93a28286839bfc1c32b06bd50b3f) setzen, indem ich die Commit-ID als „Version“ in app.yml festgelegt habe. Diesmal hat das Upgrade funktioniert. Danach konnte ich auf 3.0.0.beta16 upgraden.
Danke an alle.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.