Você pode estar ficando sem RAM e, em seguida, o oom killer encerrar alguns processos aleatórios, como o sshd, desconectando você e causando problemas?
Deveria haver alguma informação na saída do dmesg, em /var/log/messages ou na saída do journalctl se o oom killer estiver em ação.
Duvido que a falta de RAM seja o meu problema; o mais provável é que eu esteja teimosamente usando o console do PuTTY em vez do console do DO.
Portanto, vou seguir a sugestão acima de @pfaffman, especialmente depois de descobrir que o console do PuTTY se desconecta mesmo quando estou usando-o para algo completamente diferente da administração do Discourse.
Pode ser a RAM. Você tem swap?
Você já tentou ajustar a configuração de keep-alive, algo como este?
@pfaffman Eu não especifiquei nada — estou usando todas as configurações padrão do droplet, confiando que a equipe da DO garanta um comportamento razoável.
Primeiro, vou tentar definir o keep-alive como sugerido pelo @omarfilip acima. Em seguida, vou analisar a situação da memória swap, seguido pela sugestão do @pfaffman de usar o console original da DO (se a configuração do keep-alive permitir que eu continue usando o console PuTTY, vou usá-lo, pois é muito mais amigável ao usuário do que o equivalente da DO).
Tendo tantas pessoas amigáveis me ajudando, gostaria de reiterar meus motivos para tentar unir o Ghost e o Discourse: na minha opinião, é a ferramenta ideal para quem deseja escrever documentos técnicos e oferecer o melhor suporte para discutir esses documentos. Meu plano é abordar a Gestão de Identidade e Contas (IAM) utilizando vários provedores interessantes de IAM em PaaS; esse assunto não está suficientemente bem documentado (pelo menos na minha opinião, baseada em anos de uso desses serviços).
Para fazer um “teste beta” da minha ferramenta integrada Ghost/Discourse, decidi descrever todos os detalhes do processo de criação e teste dessa ferramenta. Assim, todas as pessoas que me ajudam saberão que esse esforço tem como objetivo ajudar as comunidades do Discourse, Ghost e Digital Ocean.
Se você usou a instalação de 1 clique do DigitalOcean e não a Instalação Padrão Oficial do Discourse, provavelmente não tem swap configurado. Assim, ao reconstruir, você pode ficar sem memória RAM, a menos que tenha > 2GB.
Você pode tentar executar:
cd /var/discourse
./discourse-setup
E isso criará o swap para você, se necessário.
Se você deseja ajuda com a instalação de 1 clique do DigitalOcean e quer “confiar que a equipe do DO garantirá um comportamento razoável”, então deve confiar neles para oferecer suporte.
Mas, como já estou postando, uma maneira mais fácil de confirmar que o problema não é o PuTTY (o que poderia economizar muito tempo ajustando parâmetros do PuTTY à toa) é tentar o console. Se você ainda não executou o discourse-setup, tenho quase certeza de que o problema é o espaço de swap.
@pfaffman Eu segui o processo oficial de instalação do Discourse à risca, incluindo o uso do PuTTY mencionado naquele documento oficial de instalação.
É possível que você tenha chegado à conclusão de que eu usei a instalação com um clique da DO e que eu deveria depender da DO:
Se você quer ajuda com a instalação com um clique da Digital Ocean e deseja “confiar nas pessoas da DO para garantir um comportamento razoável”, então você deve confiar nelas para te dar suporte.
Minha referência à instalação com um clique vem do e-mail recente do Discourse:
Uhuu, uma nova versão do Discourse está disponível!
Sua versão: 2.7.0.beta1
Nova versão: 2.7.0.beta2
- Atualize usando nosso fácil upgrade com um clique no navegador
Portanto, a situação atual é a seguinte:
, sabendo que você ganha a vida ajudando pessoas com o Discourse. Apesar de eu não parecer um cliente em potencial, você dedicou tempo para me tirar do apuro../launcher rebuild app.Muito obrigado a todos que forneceram partes da solução.
Oh! Mea culpa! Muito desculpas!
Então você tem swap e minha suposição estava totalmente errada. Que pena, porque seria um conserto fácil. 
Que alívio depois de eu ter te acusado falsamente!
E é terrível saber que o PuTTY é tão ruim. Não entendo como ele continua sendo o cliente SSH recomendado para Windows.
Acho que agora existe algum cliente que faz parte daquela coisa do subsistema Linux, mas a versão do Windows que eu usava regularmente era o Windows 98.
Fico feliz que você tenha resolvido!
Todos os sistemas operacionais modernos já vêm com clientes SSH incluídos, não havendo necessidade de clientes de terceiros. Mesmo no Terminal do Windows, basta digitar SSH. Deve funcionar, desde que seu Windows esteja atualizado.
Meu Deus. Sério? Da última vez que olhei (ou achei que olhei), parecia que exigia uma instalação complicada.
E ele pode usar uma chave SSH normal, e não essa besteira de PEM?
Esta longa história tem um final feliz e pode ser categorizada como uma tempestade em um copo d’água. Aprendi muito sobre o Discourse e, como consequência, planejo permanecer aqui indefinidamente. Aqui está a descrição detalhada do final feliz:
Meu problema ao fazer a atualização da Beta1 para a Beta2 se manifestou com o timeout do console do PuTTY. Interpretei isso como um crash colossal na tarefa de atualização do Discourse e passei muito tempo aprendendo os “internos” do Discourse — um buraco do coelho pelo qual estou muito feliz em ter seguido desnecessariamente.
A solução para o meu problema é extremamente simples (uma vez que você saiba onde “empurrar”) — simples como 1, 2, 3 abaixo:
(O fato de eu ter começado com um intervalo de “keep-alive” muito grande me levou a acreditar que o PuTTY é realmente um software ruim, e passei muito tempo alternando do acesso ao droplet baseado em SSH para autenticação baseada em [ID, senha], necessária para o próprio console do Digital Ocean (que é realmente ruim). Nota: essa experiência rehabilita completamente a ferramenta PuTTY.
Como já prometi a @codinghorror escrever o melhor documento possível apresentando o Discourse ao mundo, como agradecimento pela ajuda dele (e de sua equipe) para que eu entendesse o Discourse, @pfaffman me permitiu fazer com que a sugestão de @Falco fosse a primeira parte do meu documento.
Recomendo usar tmux, assim você pode reconectar à sessão que está executando a reconstrução, mesmo que seu cliente atinja o tempo limite.
@md-misko obrigado pela dica:
O ótimo sobre o tmux é que ele permite ter múltiplos painéis abertos ao mesmo tempo, cada um com seu próprio shell em execução, mas usando a mesma conexão SSH única. Além disso, você também pode ter várias “janelas” abertas simultaneamente, algo como abas com mais painéis dentro delas.
Olá @sunjam, parece que o problema pode ser resolvido com a nova versão do gem omniauth-vkontakte 1.7.0.
Criei um pull request para o mantenedor do plugin. Como solução temporária, você pode alterar o link do GitHub no seu app.yml para
- git clone https://github.com/rapekas/discourse-vk-auth
e reconstruir.