Não alterei nada conscientemente, mas hoje, quando fiz o git pull e tentei inicializar o web_only.yml, ele está dando erros, após cerca de 90 segundos do início do processo de inicialização. Estou colando apenas as últimas linhas do erro, se isso ajudar a diagnosticar:
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/bootsnap-1.15.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/bootsnap-1.15.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/zeitwerk-2.6.6/lib/zeitwerk/kernel.rb:38:in `require'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/railties-7.0.3.1/lib/rails/application.rb:348:in `require_environment!'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/railties-7.0.3.1/lib/rails/application.rb:511:in `block in run_tasks_blocks'
/var/www/discourse/vendor/bundle/ruby/3.1.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
I, [2022-12-29T10:28:07.806753 #1] INFO -- : gem install geocoder -v 1.4.4 -i /var/www/discourse/plugins/discourse-locations/gems/3.1.3 --no-document --ignore-dependencies --no-user-install
Successfully installed geocoder-1.4.4
1 gem installed
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1066 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
9b7ac0c88b42b2aa1eccb9ef291527f4afd8b71861669af66ab79dee5ed82a45
Não consigo entender por que ele não está permitindo a inicialização do mesmo arquivo yml, que antes era bem-sucedido. Meu site, no entanto, está funcionando bem.
Não encontrei nenhum ‘erro’ no ‘Discourse-Doctor’ também (só consigo procurar pela palavra ‘error’, que não estava nesse arquivo resultante do discourse doctor). Não sou um especialista, no entanto.
Você acertou em cheio. Agora consigo inicializar o contêiner web totalmente ok.!!! Muito obrigado, mais uma vez.
Mas agora todos os meus ‘mappings/locations’ anteriores de diferentes posts e usuários desapareceram.
Existe alguma alternativa? Eu sei que posso, e devo, e vou pesquisar mais sobre os tópicos desse plugin. Mas, em resumo, existe alguma solução para este problema?
Ontem, após desabilitar o plugin ‘location’, consegui reconstruir meu contêiner web_only com sucesso. Mas hoje, mesmo após desabilitar todos os plugins um por um, o bootstrapping ainda está falhando.
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' falhou com retorno #<Process::Status: pid 900 exit 137>
Localização da falha: /usr/local/lib/ruby/gems/3.1.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falhou com os parâmetros {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
bootstrap falhou com código de saída 137
** FALHA AO INICIALIZAR ** 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.
2c5f01d5ca6b216e744e11547b121e64aac0ad5e37d64d2ec5e2f279fe766c6a
EMBORA MEU SITE ESTEJA FUNCIONANDO ABSOLUTAMENTE BEM.
O que posso fazer a respeito? Por favor, me guie em alguma direção.
Sim, o contêiner já está iniciado e o site funcionando. Mas quando tento reconstruir/inicializar o mesmo contêiner (apenas web), ele dá erro. Embora ontem, ao enfrentar o mesmo problema, desabilitar o plugin ‘location’ me permitiu inicializar o mesmo com sucesso, hoje, mesmo sem fazer nenhuma alteração, o mesmo falhou.
Isso pode ser um problema? O Discourse precisa de mais de 4 GB agora (mesmo com todos os plugins desativados)? Os outros 2 sites wpress rodando na mesma droplet/instância estão quase inativos.
Poderia haver uma solução fácil para isso, além de optar por uma máquina com 8 GB de RAM?
Sim, você só tem 400 MB de memória livre, o que não permitirá que o Discourse seja reconstruído. Tente aumentar para 4/5 GB ou desligar o fórum antes de reconstruir e tente novamente.
Assumindo que os 400 MB livres são em ociosidade. A reconstrução é bastante intensiva no sistema (eu verificaria isso no Proxmox para o meu site, mas ele está offline há um tempo), e requer mais memória do que em ociosidade.
Desculpe, mas não entendi bem o significado. Você quer dizer que devo aumentar ainda mais em 4 a 5 GB? Ou seja, fazer de 4 GB para 8 ou 9 GB?
Como posso desligar meu fórum (ou seja, site)?
E
Você quer dizer que, depois de aumentar minha memória, ainda assim devo desligar meu site antes de reconstruir?
Tente executar isso na linha de comando antes de adicionar memória.
Isso pressupõe que você tenha uma instalação padrão. Certifique-se de estar no diretório /var/discourse.
Reiniciei meu servidor Ubuntu, o que me permitiu ter cerca de 700 a 800 MB de RAM livre na minha instância e o bootstrapping foi bem-sucedido. Eu teria que parar meu contêiner antes de outro BS, se outra reconstrução/BS não tivesse sido bem-sucedida após habilitar os plugins desejados.
Mas estou espantado com as novas demandas de RAM do Discourse. Como o custo da instância/droplet está quase dobrando quando passo de 4 para 8 GB de RAM. O que eu não desejo, considerando que meu site é muito, muito, muito pequeno (talvez 10 visitantes por dia). Anteriormente, a instalação padrão do Discourse mostrava exigir apenas 1 a 2 GB de RAM.
Muito obrigado por me ajudar a reconhecer o que estava dando errado.
Se possível, recomendo optar pela máquina de 8 GB, se disponível. A máquina de 2 GB é destinada a fóruns menores, e o seu parece ter bastante conteúdo.
O meu tem 4 GB com pouquíssimas visitas até agora. Considerarei adquirir 8 GB (não há 6 GB) no futuro.
A propósito, alguns artigos no Google diziam que a quantidade de memória livre não importa muito. Pois é uma memória desperdiçada que não está fazendo nada. E os usuários deveriam, em vez disso, procurar/verificar a ‘memória disponível’, que está disponível se surgir a necessidade. E no meu caso, a memória disponível é de 1,4 GB.
Como a captura de tela/artigo acima indica, ‘disponível’ inclui ‘memória de buffer’, etc., que pode ser ‘disponível para o sistema’ caso surja a necessidade. Mas não sou especialista nessas coisas.
E, ainda estou pesquisando sobre isso (novamente, não sou especialista). Embora minha suposição seja que meus outros 2 sites WordPress, que considero quase inativos, podem ter algo a ver com isso. Tentarei desativá-los em algum tempo livre e, em seguida, compararei o desempenho.
Por enquanto, meu problema de reconstrução foi resolvido, sem precisar de mais recursos e pagando quase o dobro todo mês. Graças a você.
Você pode adicionar espaço de troca (swap). Muita RAM é necessária para uma reconstrução. Além disso, como você está executando outras coisas além do Discourse no servidor, é necessária mais memória do que o mínimo. Mesmo que os outros sites não estejam recebendo tráfego, ter o outro servidor web em execução consome alguma memória.