Após instalar o Discourse com “Docker version 20.10.5, build 55c4c8” no CentOS 8, o site está em execução, mas sempre ocorre timeout nas chamadas DELETE para /draft.json.
Tenho o Apache em execução e testei tanto com proxy reverso do Apache quanto com o HAProxy; o comportamento é o mesmo.
Não sei se há alguma conexão, mas encontro muitos desses erros no arquivo unicorn.stdout.log:
==> ./shared/standalone/log/rails/unicorn.stdout.log <==
2021-03-18T10:02:25.138Z pid=108 tid=ocs ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 119
2021-03-18T10:40:09.682Z pid=119 tid=orn ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.684Z pid=119 tid=ohf ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.685Z pid=119 tid=owv ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=oob ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
2021-03-18T10:40:09.683Z pid=119 tid=omr ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Starting up 1 supervised sidekiqs
Loading Sidekiq in process id 121
53:M 18 Mar 2021 17:07:05.076 * 10 alterações em 300 segundos. Salvando...
53:M 18 Mar 2021 17:07:05.076 * Salvamento em segundo plano iniciado pelo pid 25018
25018:C 18 Mar 2021 17:07:05.126 * Banco de dados salvo no disco
25018:C 18 Mar 2021 17:07:05.127 * RDB: 2 MB de memória usados por copy-on-write
53:M 18 Mar 2021 17:07:05.177 * Salvamento em segundo plano encerrado com sucesso
53:M 18 Mar 2021 17:12:06.097 * 10 alterações em 300 segundos. Salvando...
53:M 18 Mar 2021 17:12:06.098 * Salvamento em segundo plano iniciado pelo pid 25337
25337:C 18 Mar 2021 17:12:06.145 * Banco de dados salvo no disco
25337:C 18 Mar 2021 17:12:06.145 * RDB: 2 MB de memória usados por copy-on-write
53:M 18 Mar 2021 17:12:06.198 * Salvamento em segundo plano encerrado com sucesso
Ainda não consigo excluir posts, convites e modificações de posts inválidas.
Parece ser um problema em todas as chamadas do método HTTP DELETE. Posso sugerir que o Discourse use POST em vez de DELETE? Parece-se com How can Discourse make POST instead of DELETE for "smart" CDN?, mas não estou usando nenhum CDN, apenas um servidor virtual comum com instalação do CentOS e Docker seguindo as instruções do site do Discourse.
Parte do log do Haproxy com erros 408 em solicitações HTTP DELETE. O que pode estar “descartando” as solicitações DELETE, @codinghorror? Se essas solicitações DELETE chegarem ao haproxy, elas também deveriam chegar ao software dentro do Docker. Algo lá dentro pode ser “responsável” pelo problema?
Este é o production.log. Nunca vejo uma solicitação de exclusão aparecer, mas vejo tudo o mais registrado (abrir post, modificar, salvar, etc.):
Completed 200 OK in 81ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 14861)
Started GET "/composer_messages?composer_action=edit&topic_id=10&post_id=13" for 176.243.226.205 at 2021-03-20 15:51:09 +0100
Processing by ComposerMessagesController#index as JSON
Parameters: {"composer_action"=>"edit", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 1191ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 16940)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:14 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 9ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3192)
Started PUT "/t/e-previsto-un-ritorno-di-freddo-nutro/10" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by TopicsController#update as */*
Parameters: {"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1, "slug"=>"e-previsto-un-ritorno-di-freddo-nutro", "topic_id"=>"10", "topic"=>{"title"=>"E' previsto un ritorno di freddo, nutro?", "category_id"=>1}}
Completed 200 OK in 19ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 5149)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"closed", "topic_id"=>"10"}
Completed 200 OK in 10ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 3159)
Started PUT "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:17 +0100
Processing by PostsController#update as */*
Parameters: {"post"=>{"edit_reason"=>"", "cooked"=>"<p>post di test per vedere. ssss</p>", "raw"=>"post di test per vedere. ssss", "topic_id"=>"10", "raw_old"=>""}, "id"=>"13"}
Completed 200 OK in 3296ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 86638)
Started GET "/t/10.json" for 176.243.226.205 at 2021-03-20 15:51:20 +0100
Processing by TopicsController#show as JSON
Parameters: {"id"=>"10"}
Completed 200 OK in 143ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 52707)
Started GET "/draft.json?draft_key=topic_10" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by DraftController#show as JSON
Parameters: {"draft_key"=>"topic_10"}
Completed 200 OK in 38ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 4317)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:27 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 16ms (Views: 0.1ms | ActiveRecord: 0.0ms | Allocations: 5026)
Started POST "/presence/publish" for 176.243.226.205 at 2021-03-20 15:51:29 +0100
Processing by Presence::PresencesController#handle_message as */*
Parameters: {"state"=>"editing", "topic_id"=>"10", "post_id"=>"13"}
Completed 200 OK in 20ms (Views: 0.3ms | ActiveRecord: 0.0ms | Allocations: 3304)
Started GET "/posts/13" for 176.243.226.205 at 2021-03-20 15:51:38 +0100
Processing by PostsController#show as JSON
Parameters: {"id"=>"13"}
Completed 200 OK in 121ms (Views: 0.2ms | ActiveRecord: 0.0ms | Allocations: 56890)
Isso significa que seu proxy reverso está mal configurado e está descartando as solicitações que não são GET/POST. Esse é um problema bastante comum, e uma das razões pelas quais fornecemos um proxy reverso pré-configurado dentro do container, para que as pessoas não precisem se preocupar com isso.
Se você remover o HAProxy e permitir que o próprio container escute na porta 80/443, o problema ainda ocorre?
Certifique-se de que `gem install libv8 -v '8.4.255.0' --source 'https://rubygems.org/'` tenha sucesso antes de executar o bundler.
No Gemfile:
mini_racer foi resolvido para 0.3.1, que depende de
libv8
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:220:in `handle_error'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:102:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer/parallel_installer.rb:71:in `call'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:270:in `install_in_parallel'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:210:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:90:in `block in run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:12:in `block in lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `open'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/process_lock.rb:9:in `lock'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:72:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/installer.rb:24:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli/install.rb:64:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:259:in `block in install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/settings.rb:115:in `temporary'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:258:in `install'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:49:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.15/exe/bundle:37:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
I, [2021-03-20T23:42:40.998961 #1] INFO -- : Terminando processos assíncronos
I, [2021-03-20T23:42:40.998991 #1] INFO -- : Enviando INT para 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 pid: 66
I, [2021-03-20T23:42:40.999030 #1] INFO -- : Enviando TERM para exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 183
2021-03-20 23:42:40.999 UTC [66] LOG: recebida solicitação de desligamento rápido
183:signal-handler (1616283760) Recebido SIGTERM agendando desligamento...
2021-03-20 23:42:41.013 UTC [66] LOG: abortando quaisquer transações ativas
2021-03-20 23:42:41.014 UTC [66] LOG: worker de fundo "logical replication launcher" (PID 75) saiu com código de saída 1
2021-03-20 23:42:41.016 UTC [70] LOG: desligando
183:M 20 Mar 2021 23:42:41.058 # Solicitação de desligamento pelo usuário...
183:M 20 Mar 2021 23:42:41.058 * Salvando o snapshot final do RDB antes de sair.
183:M 20 Mar 2021 23:42:41.061 * Banco de dados salvo no disco
183:M 20 Mar 2021 23:42:41.061 # Redis está pronto para sair, tchau tchau...
2021-03-20 23:42:41.263 UTC [66] LOG: sistema de banco de dados desligado
FALHA
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development' falhou com retorno #<Process::Status: pid 348 exit 5>
Localização da falha: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec falhou com os parâmetros {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'"]}
9b0ca932a7dd52ccdd11e268910e3edcd8369c0c08f65e7f8686d542b9be473b
** FALHA AO INICIAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
➜ discourse git:(master) ✗
@Falco tentei a configuração oficial novamente, mas com “tests-passed” em vez de “stable”. Isso não gerou o erro do gem mini_racer, mas ainda enfrento o problema de DELETE, como você pode ver no vídeo com o comando tail no log do nginx e o navegador com o console aberto.
Os POSTs aparecem imediatamente no log do nginx, enquanto os DELETE só aparecem após o erro, o que é estranho.
Entendi. Como o problema não pode ser reproduzido em uma instalação nova, diria que podemos encerrar este tópico. Se o problema ocorrer novamente, por favor, abra um novo tópico com os passos para reproduzi-lo.
O comando Curl retorna um CSRF inválido e aparece imediatamente no log interno do nginx do Discourse, mas as exclusões pela interface continuam não funcionando e aparecem no log com um atraso de cerca de 35 segundos, como no vídeo que enviei.
Se eu colocar discourse.apicolturaitalianafb.it:8880 como hostname no app.yml, reconstruir e acessar http://discourse.apicolturaitalianafb.it:8880, funciona normalmente, mas não posso usá-lo dessa forma.
Como tenho o Apache rodando um site em produção, tentei colocá-lo atrás do haproxy conforme a documentação deste site, e as exclusões do Discourse param de funcionar, embora o comando curl funcione. Tentei também o proxy reverso do Apache: o curl funciona, mas as exclusões pelo Discourse não. Tentei configurar o Discourse para funcionar em um socket Unix e fazer o proxy reverso para ele, mas o problema persiste.
Para mim, a evidência é que o proxy reverso não “mata” as exclusões, mas os scripts JavaScript no Discourse, por alguma razão, param de executar as exclusões HTML corretamente.
.