Hintergrundinformationen: Die Site lautet lot.almost-dead.net, Version 2.8.0.beta4, gehostet auf Google Cloud/Compute; ich habe die offizielle Docker-basierte Anleitung zur Einrichtung befolgt. (Ich bin mit Frontend-Technologien im Browser vertraut und verstehe die Grundzüge des Cloud-Hostings, kenne mich jedoch mit AWS und nicht mit Google aus.)
Vorläufige Ursache: Ich habe die VM-Instanz gestoppt und anschließend neu gestartet (um die Umgebungsvariablen anzupassen, die Discourse bereitgestellt werden).
Als die VM wieder hochkam und die Site erneut erreichbar war, stellte ich fest, dass JS-Assets und einige Benutzer-Avatars zeitüberschritten wurden. Im Admin-Bereich lädt der Bereich „Community-Gesundheit" nicht; der Ladekreis dreht sich weiter, und in den Chrome-Entwicklertools zeigt der Reiter „Netzwerk" an, dass alle /message-bus/.../poll-Anfragen fehlgeschlagen sind. Die Upgrade-Seite (/admin/upgrade) schlägt fast sofort fehl, und Chrome zeigt den Fehlercode ERR_FAILED an. Beim Durchsuchen von Themen sehe ich fehlgeschlagene POST-Anfragen mit ERR_CONNECTION_REFUSED und von JS initiierte fehlgeschlagene GET-Anfragen mit ERR_FAILED. (Dies stammt von einem Browser, in dem die Login-Cookies für mein Admin-Konto gesetzt sind.)
Das Laden der Site über eine frische Browser-Instanz führt zu der Chrome-Fehlermeldung ERR_CONNECTION_REFUSED.
Was ich versucht habe:
Serverseitiger Neuaufbau – sudo ./launcher rebuild app scheint erfolgreich zu sein, aber das Verhalten der Site hat sich nicht geändert
Ich habe auch versucht, Plugins auszukommentieren und neu aufzubauen, ebenfalls ohne Erfolg
Sicherer Modus – Die Anforderung von /safe-mode führt sofort zur ERR_FAILED-Seite in Chrome
Nein, deine Seite ist nicht wieder online, sie ist komplett ausgefallen. Du siehst teilweise nur noch den Cache. Für jemanden, der deine Seite noch nie besucht hat, antwortet sie überhaupt nicht. Das liegt wahrscheinlich auf Netzwerk- oder Firewall-Ebene, oder nginx startet nicht bzw. stürzt ab.
Sobald ich sudo ./launcher enter app ausgeführt habe, scheint nginx zu laufen…
root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root 548 0.0 0.0 2156 64 ? Ss 07:04 0:00 runsv nginx
root 558 0.0 0.1 55236 2524 ? S 07:04 0:00 nginx: master process /usr/sbin/nginx
www-data 567 0.0 0.2 55996 5068 ? S 07:04 0:00 nginx: worker process
www-data 568 0.0 0.0 55996 1628 ? S 07:04 0:00 nginx: worker process
www-data 569 0.0 0.0 55792 1680 ? S 07:04 0:00 nginx: cache manager process
root 23179 0.0 0.0 6140 884 pts/1 S+ 21:23 0:00 grep nginx
Ich bin mit Google Cloud nicht so vertraut, um zu wissen, wonach ich in den Netzwerk- oder Firewall-Einstellungen suchen soll… Mir ist aufgefallen, dass die VM-Instanz die Tags „http-server" und „https-server" besitzt und dass das Firewall-System diese Tags verwendet, um die integrierten Regeln „default-allow-http" und „default-allow-https" auf Instanzen mit diesen Tags anzuwenden. Das klingt für mich korrekt, und nslookup zeigt, dass die von mir verwendete Subdomain auf die externe IP-Adresse aufgelöst wird, die in der Google-Benutzeroberfläche aufgeführt ist. Dennoch kann die Außenwelt auf die Instanz nicht zugreifen.
Hallo,
ein langer Atem, aber das letzte Mal, als ich einen Redis-Fehler sah, hing er irgendwie damit zusammen (oder lag zumindest im selben Themenbereich), dass SSL-Zertifikate fehlten.
Vielleicht hilft ./launcher logs app weiter?
Es scheint, mein Problem bestand darin, dass die VM mit einer anderen IP-Adresse wieder hochgefahren ist und ich meinen A-Eintrag anpassen musste, um auf die neue Adresse zu verweisen.
Es scheint, mein Problem bestand darin, dass die VM mit einer anderen IP-Adresse wieder hochgefahren ist und ich meinen A-Eintrag anpassen musste, um auf die neue Adresse zu verweisen.