Pourriez-vous manquer de mémoire vive (RAM), ce qui entraînerait que le tueur OOM (OOM killer) termine certains processus aléatoires comme sshd, vous déconnectant ainsi et causant des problèmes ?
Il devrait y avoir des informations dans la sortie de dmesg, /var/log/messages ou la sortie de journalctl si le tueur OOM est actif.
Je doute que le manque de RAM soit mon problème ; c’est plutôt le fait que j’utilise obstinément la console PuTTY au lieu de la console DO.
Je vais donc passer à la suggestion de @pfaffman ci-dessus, d’autant plus que j’ai découvert que la console PuTTY se déconnecte même lorsque je l’utilise pour quelque chose de totalement différent de la gestion de Discourse.
La RAM pourrait être en cause. Avez-vous de l’espace d’échange ?
Avez-vous essayé d’ajuster le paramètre de maintien de la connexion, comme ceci ?
@pfaffman Je n’ai rien spécifié — j’utilise toutes les valeurs par défaut des droplets, en me fiant à l’équipe de DO pour garantir un comportement raisonnable.
D’abord, je vais essayer de définir le keep-alive comme suggéré par @omarfilip ci-dessus, puis je vérifierai la situation concernant l’espace d’échange, suivi de la suggestion de @pfaffman d’utiliser la console originale de DO (si le paramètre keep-alive me permet de continuer à utiliser la console PuTTY, je l’utiliserai car elle est beaucoup plus conviviale que l’équivalent de DO.
Avec autant de personnes sympathiques pour m’aider, je souhaite réitérer mes raisons de vouloir assembler Ghost et Discourse : à mon avis, c’est l’outil idéal pour quelqu’un qui souhaite rédiger des documents techniques et offrir le meilleur support pour discuter de ces documents. Mon intention est d’aborder la gestion des identités et des comptes (IAM) en utilisant plusieurs fournisseurs IAM PaaS intéressants ; ce sujet n’est pas suffisamment bien documenté (du moins à mon avis, basé sur des années d’utilisation de ces services).
Afin de « tester en bêta » mon outil intégré Ghost/Discourse, j’ai décidé de décrire tous les détails du processus de création et de test de cet outil. Ainsi, toutes les personnes qui m’aident doivent savoir que cet effort vise à aider les communautés Discourse, Ghost et Digital Ocean.
Si vous avez utilisé l’installation en un clic de DigitalOcean et non l’installation standard officielle de Discourse, il est probable que vous n’ayez pas configuré d’espace d’échange (swap). Ainsi, lors de la reconstruction, vous manquerez de mémoire vive (RAM), sauf si vous en avez plus de 2 Go.
Vous pouvez essayer d’exécuter :
cd /var/discourse
./discourse-setup
Cela créera un espace d’échange pour vous si nécessaire.
Si vous souhaitez obtenir de l’aide concernant l’installation en un clic de DigitalOcean et que vous voulez « vous en remettre aux équipes de DO pour garantir un comportement raisonnable », alors vous devez vous fier à leur support.
Mais puisque je poste déjà, un moyen plus simple de confirmer que le problème ne vient pas de PuTTY (ce qui pourrait vous éviter de perdre du temps à ajuster inutilement les paramètres de PuTTY) est d’essayer la console. Si vous n’avez pas encore exécuté discourse-setup, je suis presque certain que le problème vient de l’espace d’échange.
@pfaffman J’ai suivi à la lettre le processus d’installation officiel de Discourse, y compris l’utilisation de PuTTY mentionné dans ce document d’installation officiel.
Il est possible que vous ayez déduit que j’avais utilisé l’installation en un clic de Digital Ocean et que je devais donc dépendre de DO :
Si vous souhaitez obtenir de l’aide pour l’installation en un clic de Digital Ocean et que vous voulez « compter sur l’équipe de DO pour garantir un comportement raisonnable », alors vous devez compter sur eux pour vous soutenir.
Ma référence à l’installation en un clic provient du récent e-mail de Discourse :
Hourra, une nouvelle version de Discourse est disponible !
Votre version : 2.7.0.beta1
Nouvelle version : 2.7.0.beta2
- Effectuez la mise à niveau grâce à notre simple mise à niveau en un clic via le navigateur
Donc, la situation actuelle est la suivante :
, sachant que vous gagnez votre vie en aidant les gens avec Discourse. Malgré le fait que je ne ressemble pas à un client potentiel, vous avez pris le temps de m’aider à sortir de l’impasse../launcher rebuild app.Un grand merci à tous ceux qui ont fourni des éléments de la solution.
Oh ! Mea culpa ! Désolé !
Alors, vous avez bien le swap et mon hypothèse était donc fausse. C’est dommage, car cela aurait été une correction facile. 
C’est un soulagement après vous avoir faussement accusé !
Et c’est terrible d’apprendre que PuTTY est si mauvais. Je ne comprends pas comment il continue d’être le client SSH recommandé pour Windows.
Je pense qu’il existe maintenant un client intégré à ce sous-système Linux, mais la version de Windows que j’utilisais régulièrement était Windows 98.
Ravi que vous ayez résolu le problème !
Tous les systèmes d’exploitation modernes incluent nativement des clients SSH, il n’y a donc pas besoin de clients tiers. Même sous Windows Terminal, il suffit de taper SSH. Cela devrait fonctionner à condition que votre version de Windows soit à jour.
Oh là là. Vraiment ? La dernière fois que j’ai regardé (du moins je le pensais), cela nécessitait une installation qui semblait complexe.
Et cela peut utiliser une clé SSH normale, et non cette histoire de fichier PEM ?
Cette longue histoire a une fin heureuse et pourrait être qualifiée de tempête dans un verre d’eau. J’ai beaucoup appris sur Discourse et, par conséquent, je prévois de rester indéfiniment. Voici la description détaillée de la fin heureuse :
Mon problème de mise à niveau de Beta1 vers Beta2 s’est manifesté par un délai d’expiration de la console PuTTY. J’ai interprété cela comme un crash colossal dans la tâche de mise à niveau de Discourse et j’ai passé beaucoup de temps à apprendre les « mécanismes internes » de Discourse — un chemin que j’ai suivi inutilement, mais avec plaisir.
La solution à mon problème est extrêmement simple (une fois que l’on sait où « pousser ») — simple comme 1, 2, 3 ci-dessous :
@Falco a ouvert nos « yeux collectifs » en suggérant simplement d’utiliser OpenSSH intégré à Windows 10 (grâce à Scott Hanselman).
Puisque j’ai déjà promis à @codinghorror d’écrire le meilleur document possible présentant Discourse au monde, en guise de remerciement pour son aide (et celle de son équipe) m’ayant permis de comprendre Discourse, @pfaffman m’a laissé faire de la suggestion de @Falco la première partie de mon document.
Je recommande d’utiliser tmux, de cette façon, vous pouvez vous reconnecter à la session exécutant rebuild même si votre client expire.
@md-misko merci pour l’astuce :
Le point fort de tmux, c’est qu’il vous permet d’ouvrir plusieurs volets simultanément, chacun avec son propre shell en cours d’exécution, tout en utilisant une seule et même connexion SSH. Qui plus est, vous pouvez également ouvrir plusieurs « fenêtres » en même temps, un peu comme des onglets contenant davantage de volets.
Salut @sunjam, il semble que le problème puisse être résolu avec la nouvelle version de la gemme omniauth-vkontakte 1.7.0.
J’ai créé une demande de tirage pour le mainteneur du plugin. En attendant, vous pouvez remplacer le lien GitHub dans votre fichier app.yml par :
- git clone https://github.com/rapekas/discourse-vk-auth
puis reconstruire.