J’essaie de configurer Discourse sur un serveur. Je l’ai déjà fait plusieurs fois, car je teste un script pour corriger divers aspects des archives mbox de 18 ans d’activité de listes de diffusion avant de les importer dans Discourse. Cela a fonctionné les fois précédentes.
En revenant à cela après avoir mis le travail en pause pendant un certain temps, j’ai exécuté ./discourse-setup et j’ai obtenu des erreurs de Let’s Encrypt en raison du dépassement des limites de taux (car j’ai fait de nombreuses tentatives auparavant). Pour contourner cela, j’ai modifié containers/app.yml pour supprimer les deux modèles Let’s Encrypt (je n’ai pas besoin de HTTPS pour mes tests) et j’ai exécuté ./launcher rebuild app.
Malheureusement, j’obtiens maintenant “502 Bad gateway – nginx” lorsque j’accède au site. La sortie de ./launcher logs app contient un tas de ces erreurs :
/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
Étant donné que cela a fonctionné par le passé, cela pourrait avoir plusieurs causes :
Un changement récent dans Discourse.
Le fait que je n’utilise pas Let’s Encrypt.
Le fait que j’ai également modifié les paramètres de messagerie (je doute que cela ait de l’importance, cependant).
Si c’est prévu, l’option pour ignorer le SSL ne devrait-elle pas être supprimée ? Je veux dire, aucune option de configuration n’est préférable à une option de configuration qui ne fonctionne pas…
J’ai découvert que je pouvais utiliser l’installation de test de Let’s Encrypt, ce que j’ai fait en utilisant ce diff :
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
- file:
path: "/etc/nginx/letsencrypt.conf"
Maintenant, la certification semble correcte, mais l’erreur persiste, suggérant qu’elle n’est effectivement pas liée.
[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
Je ne suis pas sûr de ce qu’il faut faire ensuite.
Juste pour vérifier, maintenant que ma limitation de quota Let’s Encrypt a expiré, j’ai essayé sans appliquer le correctif ci-dessus. Voici ce que j’ai obtenu :
[Lun 14 août 2023 19:57:34 UTC] Votre certificat se trouve dans : /shared/letsencrypt/lilypond.community_ecc/lilypond.community.cer
[Lun 14 août 2023 19:57:34 UTC] Votre clé de certificat se trouve dans : /shared/letsencrypt/lilypond.community_ecc/lilypond.community.key
[Lun 14 août 2023 19:57:34 UTC] Le certificat CA intermédiaire se trouve dans : /shared/letsencrypt/lilypond.community_ecc/ca.cer
[Lun 14 août 2023 19:57:34 UTC] Et les certificats de chaîne complète se trouvent ici : /shared/letsencrypt/lilypond.community_ecc/fullchain.cer
[Lun 14 août 2023 19:57:34 UTC] Installation de la clé dans : /shared/ssl/lilypond.community_ecc.key
[Lun 14 août 2023 19:57:34 UTC] Installation de la chaîne complète dans : /shared/ssl/lilypond.community_ecc.cer
[Lun 14 août 2023 19:57:34 UTC] Exécution de la commande de rechargement : sv reload nginx
avertissement : nginx : impossible d'ouvrir supervise/ok : fichier inexistant
[Lun 14 août 2023 19:57:34 UTC] Erreur de rechargement pour :
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
erreur 2 à la recherche de 1 profondeur : impossible d'obtenir le certificat de l'émetteur
C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Ersatz Edamame E1
erreur 2 à la recherche de 1 profondeur : impossible d'obtenir le certificat de l'émetteur
Démarrage de runsvdir, PID est 6029
ok : run : redis : (pid 6038) 0s
ok : run : postgres : (pid 6041) 0s
pid du superviseur : 6042 pid d'unicorn : 6062
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': répertoire pour pid=/var/www/discourse/tmp/pids/unicorn.pid non accessible en écriture (ArgumentError)
raise ArgumentError, "répertoire pour #{var}=#{path} non accessible en écriture"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
pid du superviseur : 6126 pid d'unicorn : 6136
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': répertoire pour pid=/var/www/discourse/tmp/pids/unicorn.pid non accessible en écriture (ArgumentError)
raise ArgumentError, "répertoire pour #{var}=#{path} non accessible en écriture"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
pid du superviseur : 6190 pid d'unicorn : 6195
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/unicorn-6.1.0/lib/unicorn/configurator.rb:104:in `block in reload': répertoire pour pid=/var/www/discourse/tmp/pids/unicorn.pid non accessible en écriture (ArgumentError)
raise ArgumentError, "répertoire pour #{var}=#{path} non accessible en écriture"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
Cela ressemble à un problème d’autorisations de dossier. C’est un peu étrange car ce dossier se trouve à l’intérieur du système de fichiers du conteneur et n’est pas monté depuis l’hôte.
Vous pouvez essayer d’entrer dans le conteneur en cours d’exécution et de modifier manuellement les autorisations du dossier. Si vous avez besoin d’aide pour cela, pouvez-vous partager la sortie de
docker exec -it app ls -lah /var/www/discourse/tmp/pids
Je réinstalle à partir de zéro et j’essaie de faire plus attention aux messages de log de la construction de l’application cette fois-ci.
Je vois ceci :
153:C 16 Aug 2023 20:24:11.676 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
153:C 16 Aug 2023 20:24:11.676 # Redis version=7.0.7, bits=64, commit=00000000, modified=0, pid=153, just started
153:C 16 Aug 2023 20:24:11.676 # Configuration loaded
153:M 16 Aug 2023 20:24:11.677 * monotonic clock: POSIX clock_gettime
153:M 16 Aug 2023 20:24:11.677 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
153:M 16 Aug 2023 20:24:11.678 # Failed listening on port 6379 (TCP), aborting.
Aussi ceci :
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" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-d7aa52aa-3a92-43f5-97ca-2c6c21fe43f0 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
(J’essaierai les modifications manuelles des permissions quand la construction sera terminée.)
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 ..
Après :
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
Maintenant, la fin de ./launcher logs app ressemble à ceci :
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
Mon navigateur signale un problème HTTPS avec le site, et lorsque je choisis l’option “dangereuse” pour contourner, j’obtiens la page nginx “bad gateway”.
Voici plus d’informations. Dans le stderr de gunicorn, je vois :
/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?
Dans le log de PG, je vois :
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
ensuite :
# 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
Sous quel utilisateur postgres s’exécute-t-il dans le conteneur ? Avec les permissions ci-dessus, ce doit être root ou quelqu’un du groupe root.
Ok, j’ai donc fait chmod o+r /etc/postgresql/13/main/pg_hba.conf et le conteneur est maintenant de nouveau opérationnel.
Tout cela est un peu préoccupant - pourquoi la méthode d’installation recommandée ne fonctionne-t-elle pas immédiatement ? Mon statut de plugin inclut actuellement ceux mentionnés ci-dessus, à l’exception de data explorer que j’ai désactivé car il avait causé l’échec la dernière fois.
Lien croisé vers
qui rapporte des symptômes similaires.
Mise à jour : J’ai modifié la commande git dans la section cmd du fichier app.yml pour utiliser sudo comme décrit dans le post lié.
Je déclare que cet échec est intermittent. En 3 tentatives (entre chaque, j’ai complètement effacé le répertoire shared), cela a réussi une fois et échoué deux fois. Lorsque cela échoue, la correction manuelle des trois permissions en question, puis le redémarrage du conteneur ont abouti à ce qui semble être un système fonctionnel. Une meilleure journalisation et de meilleurs auto-tests seraient utiles pour détecter les échecs de démarrage de conteneur.
Modifier les permissions sur /var/www/discourse/tmp/pids et /etc/postgre/13/main/pg_hba.conf ne fonctionne pas pour moi.
J’avais modifié ma liste de plugins avant la reconstruction, mais même après avoir restauré la liste de plugins, j’obtiens la même ArgumentError. Sommes-nous sûrs que c’est la liste des plugins qui en est la cause ?
Après avoir démarré le conteneur, je vois des fichiers écrits dans le répertoire pids. Mon journal du lanceur s’arrête après ceci :
J’ai le même problème que celui décrit dans ce fil de discussion. J’ai essayé d’installer Discourse aujourd’hui sur un nouveau serveur, cela a échoué à cause d’une permission d’écriture manquante.
La « correction » avec chown/chmod ne fonctionne pas pour moi, la permission est à nouveau réinitialisée lors de ./launcher rebuild app
Alors vous avez réussi à reproduire cela sur une installation toute neuve ? C’est une information très utile, car je n’arrive pas à reproduire le problème en mettant à jour une installation existante.
Oui, j’ai essayé d’installer Discourse en suivant le guide et j’ai cru devenir fou, car tout « semblait » fonctionner mais je n’obtenais qu’une erreur « 502 ».
J’ai essayé de changer les permissions dans le conteneur sans reconstruire. Maintenant, j’obtiens ceci :
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
J’ai un second serveur, configuré exactement comme celui-ci, qui fonctionne depuis plus d’un an. Celui-ci fonctionne, arrêter le conteneur, faire un git pull, reconstruire et démarrer fonctionnait également.
J’ai donc installé un tout nouveau droplet avec Ubuntu 22.04, j’ai suivi le guide d’installation et tout s’est bien déroulé. Je ne parviens pas à reproduire ce problème sur une ancienne ou une nouvelle installation.
Quelle distribution utilisiez-vous ?
Rien de tel sur une nouvelle installation :
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
