Hallo zusammen – neu bei Discourse (sieht großartig aus!) und obwohl ich über einige allgemeine technische Fähigkeiten verfüge, würde ich mich in der Docker/Linux-VM-Welt eher als Anfänger bezeichnen.
Ich erhalte durchgehend die folgende Fehlermeldung… habe versucht, den discourse doctor auszuführen, aber ohne Erfolg. Ich hoffe, jemand kann mir den richtigen Weg aufzeigen, was hier schiefgehen könnte. Vielen Dank im Voraus! – Tim
[2021-06-11T04:09:29.733935 #1] INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2021-06-11T04:09:29.735773 #1] INFO -- : > sleep 5
2021-06-11 04:09:30.320 GMT [54] LOG: 0 8kB liegt außerhalb des gültigen Bereichs für den Parameter "shared_buffers" (16 .. 1073741823)
2021-06-11 04:09:30.322 UTC [54] FATAL: Konfigurationsdatei "/etc/postgresql/13/main/postgresql.conf" enthält Fehler
I, [2021-06-11T04:09:34.739847 #1] INFO -- :
I, [2021-06-11T04:09:34.740097 #1] INFO -- : > su postgres -c 'createdb discourse' || true
createdb: Fehler: konnte keine Verbindung zur Datenbank template1 herstellen: konnte keine Verbindung zum Server herstellen: Kein solcher Verzeichnis oder Datei
Ist der Server lokal aktiv und akzeptiert
Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:34.860266 #1] INFO -- :
I, [2021-06-11T04:09:34.860745 #1] INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: Fehler: konnte keine Verbindung zum Server herstellen: Kein solcher Verzeichnis oder Datei
Ist der Server lokal aktiv und akzeptiert
Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.023426 #1] INFO -- :
I, [2021-06-11T04:09:35.023810 #1] INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: Fehler: konnte keine Verbindung zum Server herstellen: Kein solcher Verzeichnis oder Datei
Ist der Server lokal aktiv und akzeptiert
Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.137806 #1] INFO -- :
I, [2021-06-11T04:09:35.138325 #1] INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: Fehler: konnte keine Verbindung zum Server herstellen: Kein solcher Verzeichnis oder Datei
Ist der Server lokal aktiv und akzeptiert
Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2021-06-11T04:09:35.257190 #1] INFO -- :
I, [2021-06-11T04:09:35.257476 #1] INFO -- : Asynchrone Prozesse werden beendet
FEHLGESCHLAGEN
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' fehlgeschlagen mit Rückgabewert #<Process::Status: pid 80 exit 2>
Fehlerort: /pups/lib/pups/exec_command.rb:112:in `spawn'
Ausführung fehlgeschlagen mit den Parametern "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
14ef6216494c846091ea6ce48143e2f25018b9d2579b6d4d0021d605f7f5e145
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen; es kann mehr als eine geben.
Hallo @Meathead40,
ich habe möglicherweise das gleiche Problem.
Ich habe Discourse im Juni auf Oracle Free eingerichtet. Jetzt habe ich das Setup-Skript erneut ausgeführt, um ein paar Parameter im Zusammenhang mit den E-Mail-Einstellungen zu ändern.
Der erste Fehler, den ich im Log zurückverfolgen kann, lautet: FATAL: configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors. In meinem Fall existiert diese Datei jedoch nicht. Außerdem wird der PostgreSQL-Dienst nicht ausgeführt (er ist gar nicht als Dienst verfügbar).
Bist du in der Lage gewesen, dieses Problem zu lösen? Hat noch jemand anderes dasselbe erlebt?
Vielen Dank für die Vorschläge. Ich habe es geschafft, weitere Informationen zu sammeln.
Dies stammt aus dem Protokoll, ungefähr zum Zeitpunkt des Fehlers (die vorherigen Nachrichten stammen von Tagen zuvor):
2021-08-02 13:33:16.980 UTC [2419] LOG: received smart shutdown request
2021-08-02 13:33:28.273 UTC [2419] LOG: background worker "logical replication launcher" (PID 2442) exited with exit code 1
2021-08-02 13:33:28.344 UTC [2437] LOG: shutting down
2021-08-02 13:33:28.552 UTC [2419] LOG: database system is shut down
Ich habe auch die Konfiguration des gemeinsam genutzten Puffers erhalten:
shared_buffers = 128MB # min 128kB
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
Sicher, und vielen Dank nochmals für die Unterstützung.
Ich führe das Setup auf einer bestehenden Installation durch, um einige Konfigurationsparameter zu ändern. Der erste Teil des Skripts erkennt Folgendes:
sudo ./discourse-setup
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
which: no docker.io in (/sbin:/bin:/usr/sbin:/usr/bin)
The configuration file containers/app.yml already exists!
. . . reconfiguring . . .
Saving old file as app.yml.2021-08-03-102829.bak
Stopping existing container in 5 seconds or Control-C to cancel.
+ /bin/docker stop -t 30 app
app
Found 0GB of memory and 1 physical CPU cores
setting db_shared_buffers = 0MB
setting UNICORN_WORKERS = 0
containers/app.yml memory parameters updated.
Weiter geht es mit der Übergabe aller Konfigurationsparameter und schließlich dem Build-Vorgang… Das sollte der Hinweis sein, den Sie suchen:
2021-08-03 10:30:37.709 GMT [55] LOG: 0 8kB is outside the valid range for parameter "shared_buffers" (16 .. 1073741823)
2021-08-03 10:30:37.713 UTC [55] FATAL: configuration file "/etc/postgresql/13/main/postgresql.conf" contains errors
Das ist kein gutes Zeichen! Diese Zahl sollte direkt aus der Ausgabe von
free -g --si | awk ' /Mem:/ {print $2} '
stammen.
Dabei wird 703 MByte gemeldet, was (offiziell) zu wenig ist, damit Discourse gut funktioniert. Wenn du es riskant ausprobieren möchtest (und keinen Support erwarten kannst), könntest du die magische Zahl 990 in
bearbeiten.
Ich denke, du brauchst eine größere Instanz mit mehr RAM.
In der Konfigurationsdatei ist die Prüfung zwar immer noch deaktiviert, aber ich vermute, sie wird überschrieben? Ich werde versuchen, den Wert wie von dir angegeben zu ändern und berichten, was passiert.
Ich habe es geschafft, die Konfiguration abzuschließen und den Neuaufbau durchzuführen. Die Schritte waren folgende:
Den Speichercheck (#check_disk_and_memory) in /var/discourse/discourse-setup auskommentieren (ich bin mir nicht sicher, ob dies notwendig ist)
Den Befehl sudo ./discourse-setup aus dem Ordner /var/discourse ausführen (dies generiert die Datei /var/discourse/containers/app.yml und versucht, mit dem Build fortzufahren, der wie oben beschrieben fehlschlagen wird)
Die app.yml bearbeiten, um db_shared_buffers: “128MB” und UNICORN_WORKERS: 1 explizit festzulegen
Einen Neuaufbau mit sudo ./launcher rebuild app starten (aus dem Ordner /discourse)
Ich weiß, dass dies am Rand der Anforderungen liegt, aber ich werde das Verhalten der Instanz genau beobachten.
Schön, dass das geklärt ist. Im verlinkten Thread und im hier darauf verweisenden Thread finde ich es weitaus sinnvoller, die Zahl 990 für die „magische Verzeihung
Hallo Ed,
ich stimme zu, ich werde die Nummer ändern. Ich bin ziemlich überrascht über so wenig Speicher. Die Oracle (Free Tier)-Instanzspezifikationen geben 1 GB Speicher an, doch die kostenlose Version bietet nur etwa 60–70 % davon. Ich bin etwas verwirrt und weiß nicht, woran das liegt.
Das wurde bereits erwähnt – ich finde, Oracle verhält sich hier etwas hinterhältig und bietet deutlich weniger als 1 GB an, was sie bei der Beschreibung dann aber auf 1 GB aufrunden:
Vielleicht ist die wichtigste fehlende Anweisung: Verwenden Sie nicht das Standard-Server-Image. Discourse benötigt 1 GB RAM (oder etwas mehr oder weniger), und aus irgendeinem Grund bleibt beim Oracle-Linux-Image nicht genug Speicher übrig. Ich weiß nicht, ob CentOS funktioniert, aber das Ubuntu-Image ist in Ordnung. Stellen Sie einfach sicher, dass Sie die vollständige Installation2 und nicht die „Minimale
Ich vermute, dass das Standard-Oracle-Linux eine Menge Dinge enthält, die für die Installation von Discourse nicht benötigt werden. Vermutlich liegt sein Hauptanwendungsfall im Hosting von Oracle-Datenbankservern. Zum Glück funktioniert das Ubuntu-Image einwandfrei. Meine Testseite/Kommentarhost läuft noch. (Allerdings nicht viel Aktivität.)