Ich versuche, Discourse auf einem Server einzurichten. Das habe ich schon ein paar Mal gemacht, da ich ein Skript teste, um verschiedene Aspekte der mbox-Archive von 18 Jahren Mailinglistenaktivität zu korrigieren, bevor ich sie in Discourse importiere. Es hat bei den vorherigen Versuchen funktioniert.
Als ich nach einer Pause die Arbeit wieder aufnahm, führte ich ./discourse-setup aus und erhielt Fehler von Let’s Encrypt, da ich die Ratenbegrenzungen überschritten hatte (da ich zuvor viele Versuche unternommen hatte). Um dies zu umgehen, habe ich containers/app.yml bearbeitet, um die beiden Let’s Encrypt-Vorlagen zu entfernen (ich brauche kein HTTPS für meine Tests) und führte ./launcher rebuild app aus.
Leider erhalte ich jetzt “502 Bad Gateway – nginx”, wenn ich auf die Seite zugreife. Die Ausgabe von ./launcher logs app enthält eine Reihe dieser Fehler:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)
raise ArgumentError, "directory for #{var}=#{path} not writable"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (90) - No such process
config/unicorn_launcher: line 15: kill: (90) - No such process
(80) exiting
Da es in der Vergangenheit funktioniert hat, könnte dies mehrere Ursachen haben:
Eine kürzliche Änderung in Discourse.
Die Tatsache, dass ich Let’s Encrypt nicht verwende.
Die Tatsache, dass ich auch die E-Mail-Einstellungen geändert habe (ich bezweifle, dass das eine Rolle spielt).
Wenn dies erwartet wird, sollte die Option zum Überspringen von SSL nicht entfernt werden? Ich meine, keine Konfigurationsoption ist besser als eine Konfigurationsoption, die nicht funktioniert…
Ich habe festgestellt, dass ich die Testeinrichtung von Let’s Encrypt verwenden könnte, was ich mit diesem Diff getan habe:
diff --git a/templates/web.letsencrypt.ssl.template.yml b/templates/web.letsencrypt.ssl.template.yml
index ba5f551..17e5614 100644
--- a/templates/web.letsencrypt.ssl.template.yml
+++ b/templates/web.letsencrypt.ssl.template.yml
@@ -16,7 +16,7 @@ hooks:
- install -d -m 0755 -g root -o root $LETSENCRYPT_DIR
- cd /root/acme.sh
- cd /root/acme.sh
- - cd /root/acme.sh
+ - cd /root/acme.sh --server letsencrypt_test
- file:
path: "/etc/nginx/letsencrypt.conf"
Jetzt scheint die Zertifizierung in Ordnung zu sein, aber der Fehler besteht weiterhin, was darauf hindeutet, dass er tatsächlich nicht damit zusammenhängt.
[Mon 14 Aug 2023 10:55:24 AM UTC] Your cert is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.cer
[Mon 14 Aug 2023 10:55:24 AM UTC] Your cert key is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.key
[Mon 14 Aug 2023 10:55:24 AM UTC] The intermediate CA cert is in: /shared/letsencrypt/lilypond.community_ecc/ca.cer
[Mon 14 Aug 2023 10:55:24 AM UTC] And the full chain certs is there: /shared/letsencrypt/lilypond.community_ecc/fullchain.cer
[Mon 14 Aug 2023 10:55:25 AM UTC] Installing key to: /shared/ssl/lilypond.community_ecc.key
[Mon 14 Aug 2023 10:55:25 AM UTC] Installing full chain to: /shared/ssl/lilypond.community_ecc.cer
[Mon 14 Aug 2023 10:55:25 AM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Mon 14 Aug 2023 10:55:25 AM UTC] Reload error for :
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
error 2 at 1 depth lookup: unable to get issuer certificate
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Ersatz Edamame E1
error 2 at 1 depth lookup: unable to get issuer certificate
Started runsvdir, PID is 6029
ok: run: redis: (pid 6040) 0s
ok: run: postgres: (pid 6041) 0s
supervisor pid: 6039 unicorn pid: 6062
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)
raise ArgumentError, "directory for #{var}=#{path} not writable"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6062) - No such process
config/unicorn_launcher: line 15: kill: (6062) - No such process
(6039) exiting
Ich bin mir nicht sicher, was ich als Nächstes tun soll.
Nur zur Überprüfung, jetzt, da meine Let’s Encrypt-Kontingentbeschränkung abgelaufen ist, habe ich es ohne Anwendung des obigen Patches versucht. Das habe ich erhalten:
[Mon 14 Aug 2023 07:57:34 PM UTC] Your cert is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.cer
[Mon 14 Aug 2023 07:57:34 PM UTC] Your cert key is in: /shared/letsencrypt/lilypond.community_ecc/lilypond.community.key
[Mon 14 Aug 2023 07:57:34 PM UTC] The intermediate CA cert is in: /shared/letsencrypt/lilypond.community_ecc/ca.cer
[Mon 14 Aug 2023 07:57:34 PM UTC] And the full chain certs is there: /shared/letsencrypt/lilypond.community_ecc/fullchain.cer
[Mon 14 Aug 2023 07:57:34 PM UTC] Installing key to: /shared/ssl/lilypond.community_ecc.key
[Mon 14 Aug 2023 07:57:34 PM UTC] Installing full chain to: /shared/ssl/lilypond.community_ecc.cer
[Mon 14 Aug 2023 07:57:34 PM UTC] Run reload cmd: sv reload nginx
warning: nginx: unable to open supervise/ok: file does not exist
[Mon 14 Aug 2023 07:57:34 PM UTC] Reload error for :
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
error 2 at 1 depth lookup: unable to get issuer certificate
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Ersatz Edamame E1
error 2 at 1 depth lookup: unable to get issuer certificate
Started runsvdir, PID is 6029
ok: run: redis: (pid 6038) 0s
ok: run: postgres: (pid 6041) 0s
supervisor pid: 6042 unicorn pid: 6062
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)
raise ArgumentError, "directory for #{var}=#{path} not writable"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6062) - No such process
config/unicorn_launcher: line 15: kill: (6062) - No such process
(6042) exiting
ok: run: redis: (pid 6038) 1s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 9s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 17s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 24s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 32s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 39s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 47s
ok: run: postgres: (pid 6134) 0s
supervisor pid: 6126 unicorn pid: 6136
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)
raise ArgumentError, "directory for #{var}=#{path} not writable"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6136) - No such process
config/unicorn_launcher: line 15: kill: (6136) - No such process
(6126) exiting
ok: run: redis: (pid 6038) 54s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 62s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 69s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 77s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 6038) 84s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 6038) 92s
ok: run: postgres: (pid 6193) 0s
supervisor pid: 6190 unicorn pid: 6195
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': directory for pid=/var/www/discourse/tmp/pids/unicorn.pid not writable (ArgumentError)
raise ArgumentError, "directory for #{var}=#{path} not writable"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `each'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:100:in `reload'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/http_server.rb:78:in `initialize'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `new'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/bin/unicorn:128:in `<top (required)>'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.2.0/bin/unicorn:25:in `<main>'
config/unicorn_launcher: line 71: kill: (6195) - No such process
config/unicorn_launcher: line 15: kill: (6195) - No such process
(6190) exiting
ok: run: redis: (pid 6038) 94s
Dies scheint ein Problem mit den Ordnerberechtigungen zu sein. Das ist irgendwie seltsam, da sich dieser Ordner im Dateisystem des Containers befindet und nicht vom Host gemountet ist.
Sie können versuchen, in den laufenden Container zu wechseln und die Ordnerberechtigungen manuell anzupassen. Wenn Sie dabei Hilfe benötigen, können Sie bitte die Ausgabe von
docker exec -it app ls -lah /var/www/discourse/tmp/pids
Ich installiere wieder von Grund auf und versuche dieses Mal, den Log-Meldungen beim Erstellen der App mehr Aufmerksamkeit zu schenken.
Ich sehe Folgendes:
153:C 16 Aug 2023 20:24:11.676 # oO0OoO0OoO0Oo Redis startet oO0OoO0OoO0Oo
153:C 16 Aug 2023 20:24:11.676 # Redis version=7.0.7, bits=64, commit=00000000, modified=0, pid=153, gerade gestartet
153:C 16 Aug 2023 20:24:11.676 # Konfiguration geladen
153:M 16 Aug 2023 20:24:11.677 * Monotonische Uhr: POSIX clock_gettime
153:M 16 Aug 2023 20:24:11.677 # Warnung: Konnte keinen TCP-Server-Socket erstellen *:6379: bind: Adresse bereits in Verwendung
153:M 16 Aug 2023 20:24:11.678 # Fehler beim Lauschen auf Port 6379 (TCP), Abbruch.
Außerdem dies:
I, [2023-08-16T20:24:26.172936 #1] INFO -- : cd /var/www/discourse & su discourse -c 'yarn install --frozen-lockfile & yarn cache clean'
warning " > @glint/environment-ember-loose@1.0.2" hat nicht erfüllte Peer-Abhängigkeit " @glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" hat nicht erfüllte Peer-Abhängigkeit "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" hat nicht erfüllte Peer-Abhängigkeit "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" ist inkompatibel mit der angeforderten Version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" ist inkompatibel mit der angeforderten Version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" hat nicht erfüllte Peer-Abhängigkeit " @babel/core@^7.0.0".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3@3.0.6" hat falsche Peer-Abhängigkeit " @uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3-multipart@3.1.3" hat falsche Peer-Abhängigkeit " @uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/xhr-upload@3.1.1" hat falsche Peer-Abhängigkeit " @uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" hat falsche Peer-Abhängigkeit " @uppy/core@^3.2.1".
(Ich werde die manuellen Berechtigungsänderungen versuchen, wenn es mit dem Erstellen fertig ist.)
root@ubuntu-app:/var/www/discourse# ls -lah /var/www/discourse/tmp/pids
total 8.0K
drwxr-xr-x 2 root root 4.0K Aug 16 20:47 .
drwxr-xr-x 6 root root 4.0K Aug 16 20:53 ..
Danach:
root@ubuntu-app:/var/www/discourse# ls -lah /var/www/discourse/tmp/pids
total 16K
drwxrwxr-x 1 discourse www-data 4.0K Aug 16 20:58 .
drwxr-xr-x 1 root root 4.0K Aug 16 20:53 ..
-rw-r--r-- 1 discourse www-data 5 Aug 16 20:58 unicorn.pid
Jetzt sieht das Ende von ./launcher logs app so aus:
ok: run: redis: (pid 5790) 184s
ok: run: postgres: (pid 6154) 0s
supervisor pid: 6155 unicorn pid: 6159
config/unicorn_launcher: line 71: kill: (6159) - No such process
config/unicorn_launcher: line 15: kill: (6159) - No such process
(6155) exiting
ok: run: redis: (pid 5790) 188s
ok: run: postgres: (pid 6176) 0s
supervisor pid: 6177 unicorn pid: 6181
config/unicorn_launcher: line 71: kill: (6181) - No such process
config/unicorn_launcher: line 15: kill: (6181) - No such process
(6177) exiting
ok: run: redis: (pid 5790) 192s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 200s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 5790) 208s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 215s
timeout: down: postgres: 0s, normally up, want up
ok: run: redis: (pid 5790) 223s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 230s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 5790) 238s
ok: run: postgres: (pid 6264) 0s
supervisor pid: 6260 unicorn pid: 6266
config/unicorn_launcher: line 71: kill: (6266) - No such process
config/unicorn_launcher: line 15: kill: (6266) - No such process
(6260) exiting
ok: run: redis: (pid 5790) 244s
ok: run: postgres: (pid 6283) 0s
supervisor pid: 6284 unicorn pid: 6288
Mein Browser meldet ein HTTPS-Problem mit der Seite, und wenn ich die “gefährliche” Option zum Umgehen wähle, erhalte ich die Nginx “Bad Gateway”-Seite.
Hier sind weitere Informationen. Im gunicorn stderr sehe ich:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.7/lib/active_record/connection_adapters/postgresql_adapter.rb:87:in `rescue in new_client': connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: No such file or directory (ActiveRecord::ConnectionNotEstablished)
Is the server running locally and accepting connections on that socket?
Im PG-Log sehe ich:
2023-08-21 19:24:00.721 UTC [1681] LOG: listening on Unix socket \"/var/run/postgresql/.s.PGSQL.5432\"
2023-08-21 19:24:00.728 UTC [1681] LOG: could not open configuration file \"/etc/postgresql/13/main/pg_hba.conf\": Permission denied
2023-08-21 19:24:00.728 UTC [1681] FATAL: could not load pg_hba.conf
2023-08-21 19:24:00.741 UTC [1681] LOG: database system is shut down
weiter:
# ls -l /etc/postgresql/13/main/pg_hba.conf
-rw-r----- 1 root root 4846 Aug 21 19:05 /etc/postgresql/13/main/pg_hba.conf
Unter welchem Benutzer läuft PostgreSQL im Container? Mit den obigen Berechtigungen muss es root oder jemand in der Gruppe root sein.
Ok, ich habe chmod o+r /etc/postgresql/13/main/pg_hba.conf ausgeführt und jetzt ist der Container wieder hochgefahren.
Das ist alles etwas beunruhigend – warum funktioniert die empfohlene Installationsmethode nicht sofort? Mein Plugin-Status enthält derzeit die oben aufgeführten, außer Data Explorer, das ich deaktiviert habe, da es beim letzten Mal den Fehler verursacht hatte.
Querverweis auf
der ähnliche Symptome meldet.
Update: Ich habe den git-Befehl im cmd-Abschnitt der app.yml-Datei geändert, um sudo zu verwenden, wie im verlinkten Beitrag beschrieben.
Ich erkläre diesen Fehler für intermittent. Bei 3 Versuchen (zwischen denen ich das shared-Verzeichnis vollständig gelöscht habe) war es einmal erfolgreich und zweimal fehlgeschlagen. Wenn es fehlschlägt, führte die manuelle Korrektur der drei betroffenen Berechtigungen und der anschließende Neustart des Containers zu einem scheinbar funktionierenden System. Bessere Protokollierung und bessere Selbsttests wären schön, um fehlgeschlagene Container-Bootstraps zu erkennen.
Das Ändern der Berechtigungen für /var/www/discourse/tmp/pids und /etc/postgre/13/main/pg_hba.conf funktioniert bei mir nicht.
Ich hatte meine Plugin-Liste vor dem Neuerstellen geändert, aber selbst nach der Wiederherstellung der Plugin-Liste erhalte ich denselben ArgumentError. Sind wir sicher, dass die Plugin-Liste die Ursache ist?
Nach dem Starten des Containers sehe ich, dass Dateien in das pids-Verzeichnis geschrieben werden. Mein Launcher-Log endet danach
Ich habe das gleiche Problem wie in diesem Thread beschrieben. Habe versucht, Discourse heute auf einem neuen Server zu installieren, fehlgeschlagen wegen fehlender Schreibberechtigung.
Die “Korrektur” mit chown/chmod funktioniert bei mir nicht, die Berechtigung wird bei ./launcher rebuild app wieder zurückgesetzt.
Konnten Sie dies bei einer brandneuen Installation reproduzieren? Das sind sehr nützliche Informationen, da ich es bei einem Update einer bestehenden Installation nicht reproduzieren kann.
Ja, ich habe versucht, Discourse zu installieren, indem ich einfach der Anleitung gefolgt bin und dachte, ich würde verrückt werden, da alles “scheinbar” funktionierte, aber ich erhalte nur einen “502”-Fehler.
Ich habe versucht, die Berechtigungen innerhalb des Containers zu ändern, ohne neu zu bauen. Jetzt erhalte ich Folgendes:
ok: run: redis: (pid 50) 4677s
ok: run: postgres: (pid 12224) 0s
supervisor pid: 12215 unicorn pid: 12226
config/unicorn_launcher: line 71: kill: (12226) - No such process
config/unicorn_launcher: line 15: kill: (12226) - No such process
(12215) exiting
ok: run: redis: (pid 50) 4686s
ok: run: postgres: (pid 12249) 0s
supervisor pid: 12240 unicorn pid: 12251
config/unicorn_launcher: line 71: kill: (12251) - No such process
config/unicorn_launcher: line 15: kill: (12251) - No such process
(12240) exiting
ok: run: redis: (pid 50) 4695s
timeout: down: postgres: 1s, normally up, want up
ok: run: redis: (pid 50) 4703s
ok: run: postgres: (pid 12279) 0s
supervisor pid: 12275 unicorn pid: 12281
Ich habe einen zweiten Server, der genau wie dieser eingerichtet ist und seit über einem Jahr läuft. Dieser funktioniert einfach, das Stoppen des Containers, ein Git-Pull, ein Neuaufbau und Starten funktionierte ebenfalls.
Ich habe gerade einen brandneuen Droplet mit Ubuntu 22.04 eingerichtet, die Installationsanleitung ausgeführt und es hat einwandfrei funktioniert. Ich kann dieses Problem weder bei einer alten noch bei einer neuen Installation reproduzieren.
Welche Distribution hast du verwendet?
Bei einer brandneuen Installation ist nichts dergleichen zu sehen:
root@test-install:/var/discourse# cat /var/discourse/shared/standalone/log/rails/unicorn.std*
I, [2023-08-22T17:16:33.594602 #2982] INFO -- : Refreshing Gem list
I, [2023-08-22T17:16:38.624384 #2982] INFO -- : listening on addr=127.0.0.1:3000 fd=10
I, [2023-08-22T17:16:43.003213 #2982] INFO -- : starting 1 supervised sidekiqs
I, [2023-08-22T17:16:47.070059 #2982] INFO -- : master process ready
I, [2023-08-22T17:16:50.490722 #3068] INFO -- : worker=0 ready
I, [2023-08-22T17:16:52.394685 #3077] INFO -- : worker=1 ready
I, [2023-08-22T17:16:53.139229 #3085] INFO -- : worker=2 ready
I, [2023-08-22T17:16:53.518292 #3097] INFO -- : worker=3 ready
Loading Sidekiq in process id 3059
