Entschuldigen Sie bitte im Voraus, falls dies die falsche Kategorie, der falsche Ort usw. ist.
Ich betreibe seit etwa sechs Monaten eine Discourse-Seite über einen DigitalOcean VPS, ohne große Probleme. Die Admin-Seite zeigt Version 2.5.0.beta4 an. Seit gestern Abend weigert sich der Großteil des Seiteninhalts zu laden oder benötigt scheinbar eine unangemessen lange Zeit. So kann ich zwar zu Seiten wie der Startseite oder /admin navigieren, aber der eigentliche Inhalt (Beiträge, Admin-Grafiken oder andere Registerkarten) lädt nicht. Ich habe die Systemvitals überprüft: Die CPU-Auslastung pendelt bei etwa 2 %, und es gibt nur minimalen Traffic oder Festplattennutzung. Die Nutzerbasis beträgt vielleicht 10 Personen, da ich die Seite gerade erst teste bzw. einrichte. Unter diesen Umständen wirkt dieses Verhalten sehr seltsam.
Laut app.yml habe ich nur zwei Plugins: docker_manager und discourse-signatures. Ich bin der einzige Admin-Benutzer und kann bestätigen, dass seit geraumer Zeit keine Änderungen an den Seiteneinstellungen vorgenommen wurden.
Mein erster Gedanke war, die Maschine neu zu starten. Außerdem habe ich versucht, manuell ein Update durchzuführen, indem ich git pull und ./launcher rebuild app ausgeführt habe. Ich bin mir nicht sicher, worauf ich während dieses Vorgangs achten sollte, um festzustellen, ob Fehler auftreten, aber der Neuaufbau scheint abzuschließen und die Seite ist danach wieder erreichbar. Allerdings bleibt sie weiterhin bei Version 2.5.0.beta4. Ebenso führt der Versuch, auf die Seite /admin/update zuzugreifen, letztendlich zu einem Timeout. Das alles erscheint ziemlich seltsam, da die Seite arguably „funktionsfähig
Sieht so aus, als würdest du alles richtig machen.
Ich empfehle dir dringend, ein Update durchzuführen, wenn möglich – du bist ziemlich weit hinter der neuesten Version zurück. Stelle aber sicher, dass du vorher ein Backup herunterlädst, damit nichts verloren geht.
Kannst du dich per SSH einloggen und prüfen, ob der Speicherplatz erschöpft ist?
df -h
In jedem Fall ist der Speicherplatz der erste wichtige Checkpunkt. Dieser Befehl eignet sich gut, um veraltete Container zu entfernen, die Speicherplatz belegen:
./launcher cleanup app
Anschließend würde ich versuchen, die App auf die neueste Version neu zu erstellen. Lass uns wissen, ob es diesmal funktioniert und keine Fehler in der Konsole anzeigt.
Der Laufwerk, das unter /dev/vda1 auf / gemountet ist, zeigt etwa 7,9 GB freien Speicherplatz an. Ich bin nicht wirklich damit vertraut, wie die anderen Partitionen unter Ubuntu genutzt werden oder wie sie sich auf den Betrieb auswirken könnten (Discourse läuft doch in einem Container, oder?). Die restlichen scheinen die Boot-Partition usw. zu sein. Insgesamt gibt es auf dem Forum nur etwa 30–40 Beiträge, da ich es gerade teste, also scheint es dort keine Gefahr zu geben. Die Bereinigung konnte zusätzlich etwa 4 GB Speicherplatz freigeben.
Was den Neuaufbau der App betrifft: Ich habe diesen Vorgang bereits ein paar Mal durchgeführt. Während des Prozesses sehe ich keine offensichtlichen Warnmeldungen, aber am Ende erscheint auch keine Bestätigung wie „Erfolg“ – ich weiß nicht genau, nach welchen Fehler- oder Warnzeilen ich suchen soll. Er entfernt den alten Container, startet dann den Docker-Container und ist danach abgeschlossen. Ich habe es gerade noch einmal ausgeführt, und wenn ich mich mit der Seite verbinde, wird mir immer noch mitgeteilt, dass Updates verfügbar sind. Allerdings dauert es unglaublich lange, bis die aktuelle Version (2.5.0.beta4) und die zu aktualisierende Version angezeigt werden.
Ein Teil des Problems ist, dass ich die Verwaltungstools ebenfalls kaum nutzen kann, sei es wegen langsamer Antwortzeiten oder weil sie nicht geladen werden. Beispielsweise zeigt der Reiter für Backups unendlich lange nur das Ladeanimation an. Aus Interesse habe ich die Konsole auf dem Backup-Reiter geöffnet, und der Browser versucht, JavaScript-Dateien abzurufen, scheitert jedoch bei allen, und zwar langsam nacheinander.
Wenn es eine Möglichkeit gibt, über SSH mit Backups zu arbeiten, wäre das hier sicher sehr hilfreich.
Es klingt nach einem Netzwerkproblem. Nutzen Sie Cloudflare? (Falls ja, schalten Sie die orange Wolke aus).
Sie könnten einen lauten Nachbarn bei DigitalOcean haben, sodass Sie dort ein Ticket eröffnen könnten.
Es ergibt keinen Sinn, dass Sie behaupten, einen Neuaufbau durchgeführt zu haben, sich die Version aber nicht geändert hat. Ich würde denken, dass Sie das Upgrade auf PostgreSQL 12 durchführen müssten. Haben Sie beim Neuaufbau nichts dazu gesehen?
Ich bin auf DigitalOcean. Ich vermute, dass so etwas dort vorkommen könnte, aber ich bin mir nicht sicher, ob dies das Problem so konsistent oder über einen so langen Zeitraum verursachen würde. Ich denke, ich könnte das Problem mit der Website besser so beschreiben: Es scheint, als könnte die Seite normalerweise das Template oder die ‘Hülle’ der Seite laden, aber darüber hinaus scheint das Abrufen tatsächlicher Inhalte für die Seiten endlos zu laden.
Was den Neuaufbau bzw. Versionswechsel betrifft: Es könnte sein, dass ein solcher Fehler auftritt, aber ich weiß keinen guten Weg, dies zu analysieren, und ich weiß auch nicht wirklich, wonach ich suchen sollte. Als ich gerade erneut einen Neuaufbau durchführte, sah ich eine Zeile, die ungefähr ‘postgres installiert’ lautete, während die Ausgabe durchlief. Ich bin mir nicht sicher, ob dies an der Arbeit innerhalb eines Containers liegt, aber beispielsweise filtert ./launcher rebuild app | grep 'postgres' anscheinend nichts heraus, und auch ./launcher rebuild app > output.txt && grep 'postgres' output.txt nicht. Die output.txt enthält zwar Informationen, aber scheinbar nicht alles? Sie endet zumindest nicht auf die gleiche Weise wie die tatsächliche Konsolenausgabe.
Ja, ich kann mich per SSH ordnungsgemäß verbinden, und so habe ich den Neuaufbau jedes Mal durchgeführt. Und nein, nach einem Neuaufbau ist es immer noch nicht erreichbar. Ich sehe (auch nach einem Neuaufbau), dass ifconfig den Docker-Container mit einer IP-Adresse anzeigt, die sich von der Server-IP unterscheidet und die ich von meinem System-Browser aus nicht erreichen kann. Ich bin mir nicht sicher, ob das beabsichtigt ist oder nicht. ./launcher rebuild app > output.txt scheint nur einen Teil der tatsächlichen Konsolenausgabe auszugeben, aber ich kann das auch einfügen.
Ubuntu Pastebin (kurze Ausgabedatei) Ubuntu Pastebin (vollständige Ausgabe, aus dem Terminal kopiert)
Ich sehe einige Fehlermeldungen von Postgres, die besagen, dass die Datenbank ‘discourse’ bereits existiert. Sollte ich das untersuchen?
host aregames.art
aregames.art hat die Adresse 198.54.117.200
aregames.art hat die Adresse 198.54.117.199
aregames.art hat die Adresse 198.54.117.198
aregames.art hat die Adresse 198.54.117.197
Wow, das war tatsächlich ziemlich aufschlussreich – ich hatte meine Domain tatsächlich ablaufen lassen, und zufällig geschah das genau an dem Tag, als ich auf diese Probleme stieß… Ich plante, den Anbieter zu wechseln, habe dort also die automatischen Zahlungen deaktiviert und das Datum ist mir wohl entgangen. Es sieht also so aus, als wären diese IPs mit einem Parkdienst für die Domain verknüpft. Ich habe sie gerade erneuert, also werden vielleicht bald wieder die richtigen Einträge angewendet – ich bin mir nicht sicher, wie lange das normalerweise dauert, der Host meldet weiterhin diese IPs. Laut der Dokumentation sollte ich mich nicht direkt über die IP verbinden können, also kann ich vorerst wohl nicht testen, ob das funktioniert hat. Danke, dass du mich darauf hingewiesen hast.
Trotzdem bin ich immer noch etwas verwirrt bezüglich der Probleme, auf die ich anfangs gestoßen bin: Habe ich vielleicht eine zwischengespeicherte Version der Seite aufgerufen, und aufgrund der Probleme mit den Nameservern kamen die Anfragen für Inhalte nicht durch? Manche Dinge, wie beispielsweise Beiträge in einem Thread oder die Liste der Beiträge beim Öffnen von „Neueste Beiträge“, wurden zwar schließlich geladen, aber erst nach langer Wartezeit.
Update: host aregames.art scheint, wie du oben erwähnt hast, wieder auf die richtige IP und den richtigen Mailserver aufzulösen. Ich konnte mit dem discourse-setup-Skript bestätigen, dass es die DNS-Einträge als auf die IP verweisend akzeptiert. Es sieht so aus, als hätte das Setup-Skript auch den Neuaufbau ausgeführt. Allerdings führt das Navigieren zur URL zu einem „Server nicht gefunden“-Fehler. Der direkte Zugriff auf die IP über Port 443 liefert einen nginx 400 Bad Request, was irgendwie wie ein Fortschritt wirkt.
Noch eine Korrektur: Ich musste meinen Browser-Cache leeren – die Seite lädt nun in einem Inkognito-Tab völlig einwandfrei. Alles sieht wieder funktionsfähig aus! Ich schätze… das Bezahlen meiner Website war die Lösung, um die Seite hier zu reparieren.
Ja, du hast die zwischengespeicherte Ansicht verwendet.
Wir haben in Discourse 2.6 eine neue Funktion hinzugefügt, um dem Dokument eine spezifische CSS-Klasse hinzuzufügen, wenn du dich in dieser Ansicht befindest. Allerdings gibt es dafür noch kein Standard-Benutzeroberflächenelement.