Einstellungen setzen sich von selbst zurück

Unterstützung
1

Ich habe eine Discourse-Instanz, die seit einer Woche läuft, und sie zeigt einige der seltsamsten Symptome, die ich nicht lösen kann – teilweise, weil in den Logs absolut nichts Nützliches angezeigt wird.

Das auffälligste Symptom ist folgendes: Wenn ich in die Einstellungen gehe, eine Einstellung ändere und dann auf das grüne Häkchen klicke, wird die Änderung akzeptiert und alles sieht gut aus. Wenn ich die Einstellungsseite jedoch aktualisiere, kann es gut sein, dass entweder die alte oder die neue Einstellung angezeigt wird. Wenn ich weiterhin aktualisiere, wird manchmal die eine, manchmal die andere Einstellung angezeigt.

Noch schlimmer ist, dass dies nicht nur im Einstellungsbildschirm selbst auftritt, sondern sich manchmal auch die Funktionalität des Servers selbst zu ändern scheint. Wenn ich beispielsweise versuche, ein neues Logo hochzuladen, wird manchmal das alte und manchmal das neue angezeigt.

Um die offensichtliche Frage zu beantworten: Nein, ich betreibe keine mehreren Instanzen hinter einem Load Balancer, sondern nur eine einzelne Instanz.

Ich bin mir nicht sicher, ob dies zusammenhängt, aber ich habe auch bemerkt, dass das Discourse-Math-Plugin nicht richtig gerendert wird. Zwar werden die Gleichungen in der Vorschau korrekt angezeigt, doch sobald ich einen Beitrag veröffentliche, scheint das JavaScript nicht eingebunden zu werden und wird daher nicht ordnungsgemäß dargestellt. Das Math-Problem ist hier nicht die Priorität, ich erwähne es nur, falls es weitere Hinweise liefert.

Ich bin hier wirklich festgefahren. Da alle Logs normal aussehen, bin ich mir nicht einmal sicher, was ich posten soll, um Hilfe zu erhalten. Jede Idee wäre toll.

2

Das deutet auf eine schwerwiegend defekte Installation hin. Entfernen Sie alle Plugins von Drittanbietern und bauen Sie sie neu auf.

3

Ich habe das versucht, aber leider ohne Erfolg. Höchstwahrscheinlich liegt ein Fehler in meiner Installationsmethode vor.

Ich bin selbst Entwickler. Hast du eine Idee, was bei der Installation schiefgelaufen sein könnte, das zu diesem Problem führt? Vielleicht einen Hinweis darauf, wo ich debuggen und Fehlerbehebungen durchführen sollte?

4

Wie installieren Sie? Nutzen Sie den offiziellen Leitfaden auf GitHub?

5

Ursprünglich habe ich genau diesen Prozess verfolgt. Leider unterstützt er die meisten Enterprise-Level-Produktionsumgebungen, die mir zur Verfügung stehen, nicht. Die meisten Frameworks arbeiten mit Containern, starten sie und deployen sie. Aufgrund der Art des Standard-Installationsansatzes ist es nicht möglich, in diesen Tools und Umgebungen zu arbeiten.

Daher versuche ich, den Prozess zu verbessern/beheben, sodass er überall installiert werden kann, was eine standardmäßige Docker-basierte Bereitstellung unterstützt. Obwohl diese Bemühungen größtenteils funktionieren, bin ich mit dem Bug, den ich ursprünglich gepostet habe, noch nicht fertig.

Sobald es funktioniert, werde ich es natürlich für andere veröffentlichen. Ich habe das letzte Jahr darauf gewartet, dass Discourse Standard-Docker unterstützt, aber ich habe beschlossen, den Beitrag einfach selbst zu leisten. Es ist so nah dran, aber hoffentlich kann mir jemand mit mehr Erfahrung als ich sagen, wo ich suchen muss.

6

Könnt ihr bitte helfen? Selbst ein kleiner Hinweis, wo ich suchen oder debuggen soll, oder auch nur Ideen wären sehr willkommen.

7

Bist du sicher, dass die Anfrage ordnungsgemäß durchkommt? Was siehst du im Netzwerkknoten der Entwicklertools?

Das von dir beschriebene Verhalten ist typisch für eine Umgebung, die auf der JavaScript-Seite Fehler aufweist.

8

Vielen Dank, das könnte sich als sehr hilfreich erweisen. Da das MathJax-Plugin scheinbar nur sporadisch funktioniert und dann wieder aufhört, liegt es wahrscheinlich an JavaScript.

Ich habe gerade versucht, eine Einstellung nach dem Leeren des Caches zu ändern und dabei die Registerkarte „Netzwerk“ im Auge behalten. Es wurden keine Fehler angezeigt, weder vor noch nach der Änderung der Einstellung (obwohl der Fehler aufgetreten ist).

Ein Grund, warum es keinen Sinn ergibt, dass die Änderung überhaupt nicht durchkommt, ist das Verhalten: Ich nehme eine Änderung vor, aktualisiere die Seite, und die Änderung scheint rückgängig gemacht zu sein. Wenn ich jedoch einfach weiter aktualisiere (ohne zu versuchen, die Änderung ein zweites Mal vorzunehmen), erscheint die Änderung etwa in der Hälfte der Fälle. Bei jedem Aktualisieren besteht eine etwa 50-prozentige Wahrscheinlichkeit, dass entweder die alte oder die neue Einstellung angezeigt wird.

Außerdem habe ich folgenden Fehler in der Konsole gefunden, aber ich denke, er hat nichts damit zu tun?

Could not find widget actions-summary-item in registry

9

Versuchen Sie einfach den abgesicherten Modus, um alle diese Plugins schnell auszuschließen.

10

Haben Sie mehrere Web-Container ausgeführt?

11

Ich habe es wie zuvor versucht. Es hat nicht geholfen. Aber ich bin skeptisch, ob ich wirklich im abgesicherten Modus war. Ich bin zu */safe-mode gegangen, um das Dialogfeld zum Aktivieren des abgesicherten Modus zu erhalten. Ich habe es bestätigt. Was mir jedoch aufgefallen ist, ist, dass das von mir verwendete Material Design-Design weiterhin angezeigt wurde. Also, obwohl ich dachte, ich wäre im abgesicherten Modus, war ich vielleicht gar nicht wirklich dort?

Unabhängig davon ist der Fehler weiterhin aufgetreten.

12

Ich glaube nicht, dass er das tut… :wink:

13

Zwei Container: einer für Sidekiq und einer für das Discourse-Kernsystem. Nur eine Instanz des Paares. PostgreSQL und Redis laufen als gehostete Dienste auf separaten Maschinen.

14

Hoppla. Entschuldigung, das war die offensichtliche Frage, die du bereits beantwortet hast.

Edit: Vielleicht ist es das auch nicht, aber ich hatte ein ähnliches Problem, als ich eine Redis-Datenbank verwendete, die bereits von einem anderen Prozess genutzt wurde.

15

Ich glaube, ich habe herausgefunden, warum der abgesicherte Modus nicht funktionierte. Er wurde beim Neuladen deaktiviert.

Gerade im abgesicherten Modus getestet, das Problem besteht weiterhin.

16

Und die API-Antwort ist 200?

17

Das kommt darauf an, was du genau meinst. Im Netzwerk-Tab „Inspect“ zur Fehlerbehebung wird alles mit 200 angezeigt, die Konsole enthält nur den oben erwähnten Fehler (wahrscheinlich nicht relevant). In den Docker-Logs sehe ich beim Ändern der Einstellung Folgendes, was bestätigt, dass sie erfolgreich war. Doch wenn ich die Einstellungsseite neu lade, wird 50 % der Zeit die alte Einstellung und 50 % der Zeit die neue angezeigt.

> 2019-08-20T13:14:15.960335498Z Started PUT "/admin/site_settings/categories_topics" for 213.127.19.53 at 2019-08-20 13:14:15 +0000
> 2019-08-20T13:14:15.968667966Z Processing by Admin::SiteSettingsController#update as */*
> 2019-08-20T13:14:15.968951769Z   Parameters: {"categories_topics"=>"25", "id"=>"categories_topics"}
> 2019-08-20T13:14:15.978407541Z   Rendering text template
> 2019-08-20T13:14:15.978607623Z   Rendered text template (0.0ms)
> 2019-08-20T13:14:15.978834745Z Completed 200 OK in 10ms (Views: 0.6ms | ActiveRecord: 0.0ms)
> 2019-08-20T13:18:39.821498901Z [ N 2019-08-20 13:18:39.8209 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6157, application /opt/bitnami/discourse (production)
> 2019-08-20T13:18:59.866033984Z [ N 2019-08-20 13:18:59.8655 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5973, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:04.848923491Z [ N 2019-08-20 13:19:04.8484 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6018, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:08.900933057Z [ N 2019-08-20 13:19:08.9004 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 5995, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:09.499349110Z [ N 2019-08-20 13:19:09.4989 4304/T4 age/Cor/CoreMain.cpp:1146 ]: Checking whether to disconnect long-running connections for process 6041, application /opt/bitnami/discourse (production)
> 2019-08-20T13:19:29.645095032Z Creating scope :open. Overwriting existing method Poll.open.
18

Wie wurde es also installiert? Wenn Sie nicht die Standardinstallation verwenden, welche Installationsmethode und welches Paket nutzen Sie?

19

Ouch… Bitnami…

Um welche Art von Prozessen handelt es sich dabei, auf die verwiesen wird?

20

Es wird nicht die Standardinstallation verwendet, obwohl ich sie als Leitfaden zum Lernen genutzt habe. Ich musste im Grunde die Docker-Dateien schreiben bzw. anpassen, damit sie mit Docker Compose funktionieren. Sobald Docker Compose lokal funktionierte, habe ich es in seine JSON-Form umgewandelt, damit es mit den AWS-CLI-Tools verwendet werden kann.

Der Installationsprozess weicht also erheblich von der Standardinstallation ab.