Fataler Fehler beim Versuch, Docker zu starten (Oracle VM)

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 habe eine kostenlose Oracle-VM mit Oracle Linux. Ich habe die Schritte hier abgeschlossen (https://blogs.oracle.com/developers/install-run-discourse-for-free-in-the-oracle-cloud) und führe gerade den Schritt ./discourse-setup aus.

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?

Viele Grüße,
Stef

Kannst du die Ausgabe von free -m --si teilen?

Hast du im Container nachgeschaut? Hast du auch den Protokolleintrag über zu kleine shared_buffers gesehen?

In meinem Fall:

# /var/discourse/launcher enter app
# egrep shared_buffers /etc/postgresql/13/main/postgresql.conf
shared_buffers = 128MB
exit

Hallo @Falco, dies ist die Ausgabe des Befehls:
total used free shared buff/cache available
Mem: 703 359 86 7 257 207
Swap: 8388 246 8142

Hallo @Ed_S, ich erhalte folgende Meldung:

/var/discourse/launcher enter app
Cannot connect to the docker daemon - verify it is running and you have access

Kannst du mir dabei helfen?

Sie sollten hier die gleiche Datei sehen:
/var/discourse/shared/standalone/postgres_data/postgresql.conf

Idealerweise sehen Sie direkt vor dem Log-Eintrag, der einen Konfigurationsfehler meldet, eine Zeile, die den Fehler beschreibt.

Vielleicht finden Sie das Log unter:
/var/discourse/shared/standalone/log/var-log/postgres/current

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

Hmm, können wir kurz zurückgehen: Wo immer du diesen FATAL-Fehler siehst, welche wenigen Zeilen gehen ihm voraus?

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.

Ja, bis jetzt lief die Instanz einwandfrei und wurde bereits mit deaktivierter Speicherprüfung installiert. Irgendwie hängt das mit diesem Beitrag zusammen: Discourse won't install because I have 960MB of ram and not 1GB - Discourse System Administration - Unix Linux Community

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.

Hmm, das hängt stark davon ab, was du dort gemacht hast.

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.

Danke für die Unterstützung.

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:

Edit: siehe den verlinkten Blogbeitrag:

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. :wink: Zum Glück funktioniert das Ubuntu-Image einwandfrei. Meine Testseite/Kommentarhost läuft noch. (Allerdings nicht viel Aktivität.)