Há alguns avisos de "_ tem dependência de par não atendida" acima, mas este é o primeiro erro (além do "_ já existe" ao configurar o banco de dados, mas entendo que esse é o comportamento esperado).
Infelizmente, a atualização em que isso começou a acontecer foi na véspera de uma viagem de carro em família, então estava um pouco apressado e não tive tempo de solucionar o problema no momento. Mas estou obtendo isso consistentemente. O host está totalmente atualizado e não me lembro de ter feito nada particularmente único com a configuração. Coloquei /var/discourse em um volume separado da Digital Ocean há cerca de 3 meses (o que sei que Não é Recomendado™ por motivos de desempenho, mas para um fórum com centenas de usuários, achei que valia a pena o compromisso), mas funcionou bem após essa alteração, pelo que pude verificar.
Para fazer isso, eu tenho que entrar no contêiner. Eu fiz isso, e quando eu inicio o contêiner depois, a interface web mostra
Oops
O software que alimenta este fórum de discussão encontrou um problema inesperado. Pedimos desculpas pelo inconveniente.
Informações detalhadas sobre o erro foram registradas e uma notificação automática gerada. Nós daremos uma olhada nisso.
Nenhuma ação adicional é necessária. No entanto, se a condição de erro persistir, você pode fornecer detalhes adicionais, incluindo os passos para reproduzir o erro, postando um tópico de discussão na categoria de feedback do site.
./launcher logs app mostra
[Qua 19 Jul 2023 23:52:05 UTC] Domínios não alterados.
[Qua 19 Jul 2023 23:52:05 UTC] Pular, próxima hora de renovação é: 2023-08-21T00:34:21Z
[Qua 19 Jul 2023 23:52:05 UTC] Adicionar '--force' para forçar a renovação.
[Qua 19 Jul 2023 23:52:05 UTC] Instalando chave em: /shared/ssl/distroleaders.club_ecc.key
[Qua 19 Jul 2023 23:52:05 UTC] Instalando cadeia completa em: /shared/ssl/distroleaders.club_ecc.cer
[Qua 19 Jul 2023 23:52:05 UTC] Executar comando de recarga: sv reload nginx
falha: nginx: runsv não está em execução
[Qua 19 Jul 2023 23:52:05 UTC] Erro de recarga para:
Iniciado runsvdir, PID é 530
ok: run: redis: (pid 544) 0s
ok: run: postgres: (pid 543) 0s
supervisor pid: 538 unicorn pid: 575
Se eu entrar no contêiner novamente, consigo executar sv reload nginx com sucesso, mas isso não muda o comportamento.
Além disso, se eu executar ./launcher rebuild app novamente, terei que entrar no contêiner para executar bundle install novamente.
fatal: not a git repository (or any parent up to mount point /var)
Seu diretório /var/discourse não é um repositório git, o que quebra nossa atualização automática do launcher e as ferramentas que usamos para inicializar o Discourse, o que, por sua vez, significa que você está preso em uma imagem docker antiga.
Você precisa desfazer as alterações que fez para quebrar isso.
Quando você copiou os arquivos para o seu volume, você falhou em copiar .git, então você precisará cloná-lo e copiar o resto das coisas para lá.
Você provavelmente deveria fazer com que seu volume tivesse apenas os uploads, que eu assumo que é o que ocupa a maior parte do espaço, e então você pode ter apenas os uploads e backups no volume.
Meu Deus. Aposto que consigo adivinhar exatamente o que fiz e isso envolve o fato de que * não corresponde a .git em um comando rsync. Não seria a primeira vez que usei rsync para tornar minha vida mais difícil. Obrigado por pegar isso!
Existe um motivo técnico para a reconstrução não poder sair naquele ponto? Teria facilitado a solução de problemas (embora começar pelo topo em vez do fundo também teria).
Felizmente, ainda tenho o tarball pré-migração porque não perdi todas as minhas habilidades de sysadmin ao longo dos anos.
Este é o menor droplet da Digital Ocean, então é principalmente o sistema que está ocupando espaço. Uploads e backups juntos são ~100MB. Acho que o que provavelmente acabarei fazendo, se fizer uma mudança, é mudar para um droplet maior que tenha mais espaço em disco.
). O discourse-doctor também diz “Nenhum plugin não oficial detectado”.