Estou tentando configurar o Discourse em um servidor. Já fiz isso algumas vezes, pois estou testando um script para corrigir vários aspectos dos arquivos mbox de 18 anos de atividade de listas de e-mail antes de importá-los para o Discourse. Funcionou nas vezes anteriores.
Voltando a isso depois de pausar o trabalho por um tempo, executei ./discourse-setup e recebi erros do Let’s Encrypt por ter excedido os limites de taxa (já que fiz muitas tentativas antes). Para contornar isso, editei containers/app.yml para remover os dois templates do Let’s Encrypt (não preciso de HTTPS para meus testes) e executei ./launcher rebuild app.
Infelizmente, agora estou recebendo “502 Bad gateway – nginx” ao acessar o site. A saída de ./launcher logs app contém um monte desses erros:
/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
Dado que funcionou no passado, isso pode ter várias causas:
Uma mudança recente no Discourse.
O fato de eu não estar usando o Let’s Encrypt.
O fato de eu também ter alterado as configurações de e-mail (duvido que isso importe, no entanto).
Se isso é esperado, a opção de pular SSL não deveria ser removida? Quer dizer, nenhuma opção de configuração é melhor do que uma opção de configuração que não funciona…
Agora, a certificação parece OK, mas o erro ainda está lá, sugerindo que é realmente não relacionado.
[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
Parece um problema de permissão de pasta. Isso é meio estranho, pois essa pasta está dentro do sistema de arquivos do contêiner e não foi montada do host.
Você pode tentar entrar no contêiner em execução e ajustar as permissões da pasta manualmente. Se precisar de ajuda com isso, você pode compartilhar a saída de
docker exec -it app ls -lah /var/www/discourse/tmp/pids
Estou instalando do zero novamente e tentando prestar mais atenção às mensagens de log da compilação do aplicativo desta vez.
Vejo estas:
153:C 16 Aug 2023 20:24:11.676 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
153:C 16 Aug 2023 20:24:11.676 # Versão do Redis=7.0.7, bits=64, commit=00000000, modificado=0, pid=153, recém-iniciado
153:C 16 Aug 2023 20:24:11.676 # Configuração carregada
153:M 16 Aug 2023 20:24:11.677 * relógio monotônico: POSIX clock_gettime
153:M 16 Aug 2023 20:24:11.677 # Aviso: Não foi possível criar o socket de escuta TCP do servidor *:6379: bind: Endereço já em uso
153:M 16 Aug 2023 20:24:11.678 # Falha ao escutar na porta 6379 (TCP), abortando.
Também isto:
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".
(Tentarei as alterações manuais de permissão quando terminar de compilar.)
Aqui estão mais informações. No gunicorn stderr, vejo:
/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?
No log do PG, vejo:
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
além disso:
# 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
Sob qual usuário o postgres está rodando dentro do container? Com as permissões acima, ele tem que ser root ou alguém do grupo root.
Ok, então eu fiz chmod o+r /etc/postgresql/13/main/pg_hba.conf e agora o container está funcionando novamente.
Tudo isso é um pouco preocupante - por que o método de instalação recomendado não está funcionando de imediato? Meu status de plugin atualmente inclui os listados acima, exceto o data explorer, que desabilitei, pois causou a falha da última vez.
Cross-linking para
que relata sintomas semelhantes.
Atualização: Mudei o comando git na seção cmd do arquivo app.yml para usar sudo, conforme descrito no post vinculado.
Estou declarando esta falha como intermitente. Em 3 tentativas (entre cada uma delas, limpei completamente o diretório shared), uma foi bem-sucedida e duas falharam. Quando falha, corrigir manualmente as três permissões em questão e reiniciar o container resultou no que parece ser um sistema funcionando. Um melhor registro e melhores auto-testes seriam úteis para detectar falhas na inicialização do container.
Alterar as permissões em /var/www/discourse/tmp/pids e /etc/postgre/13/main/pg_hba.conf não funciona para mim.
Eu havia alterado minha lista de plugins antes da reconstrução, mas mesmo após restaurar a lista de plugins, recebo o mesmo ArgumentError. Temos certeza de que é a lista de plugins que está causando isso?
Após iniciar o contêiner, vejo arquivos sendo gravados no diretório pids. Meu log do launcher para após isso
Então você conseguiu reproduzir isso em uma instalação totalmente nova? Essa é uma informação muito útil, pois não consigo reproduzir atualizando uma existente.
Sim, tentei instalar o discourse apenas seguindo o guia e pensei que tinha enlouquecido, já que tudo “parecia” funcionar, mas só recebo um erro “502”.
Tentei alterar as permissões dentro do contêiner sem reconstruir. Agora recebo isto:
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
Tenho um segundo servidor, configurado exatamente como este, funcionando há mais de um ano. Esse simplesmente funciona, parar o contêiner, fazer um git pull, reconstruir e iniciar também funcionou.
Então, acabei de pegar um novo droplet rodando Ubuntu 22.04, segui o guia de instalação e funcionou perfeitamente. Não consigo reproduzir este problema em uma instalação antiga ou nova.
Qual distro você estava rodando?
Nada disso em uma instalação novinha em folha:
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
