Plötzlich funktioniert Discourse nicht mehr und startet nicht einmal neu mit ./launcher rebuild app. Ich habe auch alle Plugins auskommentiert.
Hier sind die Logs, wenn ich versuche, es zu starten: https://codefile.io/f/8XUuOqyEDd
Hier sind die Logs, wenn ich ./launcher rebuild app verwende. Ich sehe etwas über „failed listening on port 6379 (TCP) aborting“, aber ich habe nichts auf diesem Port laufen!
Ich glaube nicht, dass es mit deinem Problem zusammenhängt. Diese Warnung erscheint oft (immer?) während eines Rebuilds.
error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: Connection refused
Ich denke, dein Problem kommt eher daher.
Das könnte Hinweise geben:
Wird dies die Ursache dafür sein, dass es nicht funktioniert, wenn ich es ausführe (ohne ./launcher rebuild app) auszuführen?
Ich habe alle anderen Dienste auf meinem Server gestoppt und auf die neueste Ubuntu LTS-Version aktualisiert, und es zeigt immer noch das:
PG::ConnectionBad: Verbindung zum Server über Socket "/var/run/postgresql/.s.PGSQL.5432" fehlgeschlagen: Verbindung abgelehnt (PG::ConnectionBad)
Läuft der Server lokal und akzeptiert Verbindungen auf diesem Socket?
was meiner Meinung nach der Fehler ist.
Der Austausch von Vorlagen gegen 13 und sogar 15 löste das Problem nicht, was in dem zitierten Beitrag gezeigt wurde.
Verursacht durch:
PG::ConnectionBad: Verbindung zum Server über Socket „/var/run/postgresql/.s.PGSQL.5432“ fehlgeschlagen: Datei oder Verzeichnis nicht gefunden (PG::ConnectionBad)
Läuft der Server lokal und akzeptiert er Verbindungen über diesen Socket?
timeout: down: postgres: 1s, normally up, want up
Es scheint, dass die Datenbank nicht richtig startet. Die Protokolle zeigen, dass sie gelegentlich richtig startet, aber nur für kurze Zeit, das könnte also eine falsche Fährte sein.
ok: run: postgres: (pid 315501) 0s
Die Postgres-Protokolle könnten einen Hinweis auf das Problem geben, insbesondere beim Versuch, den App-Container zu starten.
tail -f shared/standalone/log/var-log/postgres/current
Hast du das PostgreSQL 15 Update durchgeführt?
Ich denke auch, dass es sich um ein unsauberes Herunterfahren handelt. Wenn du ein Backup hast, würde ich eine neue VM hochfahren und es wiederherstellen. Du kannst Eine Discourse-Site mit rsync auf einen anderen VPS verschieben befolgen und postgres_* ausschließen.
Die Alternative, die deine einzige Option ist, wenn du kein Backup hast, wird darin bestehen, eine Menge über PostgreSQL herauszufinden, über die du nichts lernen möchtest.
Wie kann ich auf meine Backups zugreifen, wenn mein Forum nicht erreichbar ist (also ich nicht zu den Administratoreinstellungen gehen und ein Backup herunterladen kann)?
Ich habe auch nichts versucht zu migrieren, ich habe es normal benutzt und über die Web-Benutzeroberfläche aktualisiert. Warum sollte die Datenbank einen unsauberen Herunterfahrvorgang haben?
Ich werde die Postgres-Protokolle bereitstellen, eine Sekunde
2025-03-22 00:30:44.110 UTC [4922] FATAL: Sperrdatei „postmaster.pid“ ist leer
2025-03-22 00:30:44.110 UTC [4922] HINT: Entweder startet ein anderer Server, oder die Sperrdatei ist ein Überbleibsel eines vorherigen Serverstart-Absturzes.
2025-03-22 00:30:45.127 UTC [4964] FATAL: Sperrdatei „postmaster.pid“ ist leer
2025-03-22 00:30:45.127 UTC [4964] HINT: Entweder startet ein anderer Server, oder die Sperrdatei ist ein Überbleibsel eines vorherigen Serverstart-Absturzes.
2025-03-22 00:30:46.151 UTC [4966] FATAL: Sperrdatei „postmaster.pid“ ist leer
2025-03-22 00:30:46.151 UTC [4966] HINT: Entweder startet ein anderer Server, oder die Sperrdatei ist ein Überbleibsel eines vorherigen Serverstart-Absturzes.
2025-03-22 00:30:47.168 UTC [4970] FATAL: Sperrdatei „postmaster.pid“ ist leer
2025-03-22 00:30:47.168 UTC [4970] HINT: Entweder startet ein anderer Server, oder die Sperrdatei ist ein Überbleibsel eines vorherigen Serverstart-Absturzes.
2025-03-22 00:30:48.192 UTC [4977] FATAL: Sperrdatei „postmaster.pid“ ist leer
2025-03-22 00:30:48.192 UTC [4977] HINT: Entweder startet ein anderer Server, oder die Sperrdatei ist ein Überbleibsel eines vorherigen Serverstart-Absturzes.
-rw------- 1 syslog kvm 0 18. März 19:48 /var/discourse/shared/standalone/postgres_data/postmaster.pid
Hier ist meine Lockdatei
Sie befinden sich unter /var/discourse/shared/standalone/backups/default
Wenn Sie den rsync-Anweisungen folgen, die ich zuvor verlinkt habe, erhalten Sie sie.
Sie ist abgestürzt oder der Server wurde neu gestartet oder es sind Dinge passiert.
Die Datenbank wird bei den meisten Upgrades von einem Satz von Tabellen (Tabellen werden hinzugefügt und geändert) auf einen anderen “migriert”.
Sie könnten versuchen, den Container zu stoppen und diese Sperrdatei zu löschen
Und schauen Sie in PG_VERSION nach, welche Version Sie haben, da ich glaube, dass Sie versucht haben, die Vorlage zu ändern.
Ja, ich habe versucht, es zu ändern, nachdem ich den Fehler gesehen hatte.
Soll ich also rm /var/discourse/shared/standalone/postgres_data/postmaster.pid ausführen, um die Sperrdatei zu löschen, und dann versuchen, neu zu erstellen?
Vielen Dank auch für Ihre Hilfe.
Würde ich diesen Befehl ausführen, um die Sperrdatei zu löschen?
rm /var/discourse/shared/standalone/postgres_data/postmaster.pid war die Lösung, danke!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.