J’ai le même problème… DO Droplet sur Ubuntu 20.04. J’ai essayé de mettre à jour Docker depuis Discourse d’abord, mais j’ai toujours eu un code d’erreur 137. J’ai donc essayé de reconstruire Discourse depuis la ligne de commande et cela s’est bloqué sur La base de données est prête à accepter les connexions. Ctrl+C n’a rien fait, j’ai donc fermé SSH et en ai ouvert un nouveau et j’ai redémarré Discourse et cela fonctionnait toujours mais n’était pas mis à jour. J’ai redémarré le droplet et j’ai essayé de mettre à jour Docker à nouveau depuis Discourse et cette fois, cela a fonctionné ! J’ai donc essayé de reconstruire Discourse à nouveau, mais cela s’est toujours bloqué au même endroit. J’ai de nouveau fermé SSH et en ai ouvert un nouveau et j’ai redémarré Discourse, mais maintenant j’ai l’écran Oops ! Mon site Discourse est donc en panne et la seule façon dont j’ai jamais pu récupérer de l’écran Oops auparavant est de reconstruire l’application, ce que je ne peux pas faire !
Je suis donc perdu car mon expérience avec Discourse et Droplet est très limitée et je ne sais pas quoi faire maintenant. docker_manager est le seul plugin utilisé dans mon app.yml, je ne peux donc que supposer que l’erreur est due au fait que Docker est une version plus récente et qu’il ne s’accorde pas avec ma version de Discourse ? Je ne sais pas. J’ai mis à jour Discourse pour la dernière fois en janvier, donc ce n’est pas si obsolète…
Mon site est donc en panne jusqu’à ce que ce problème soit résolu… À moins que je ne démarre un nouveau Droplet, que je ne réinitialise tout et que je ne restaure la sauvegarde Discourse que j’ai faite ? Est-ce ma seule option à ce stade ?
L’erreur 137 est due à un manque de mémoire. J’essaierais d’ajouter plus de swap. Si vous n’avez que 1 Go de RAM, je la redimensionnerais à 2 Go et j’ajouterais peut-être aussi 3 ou 4 Go de swap.
Vous pourriez essayer un
./launcher start app
Mais je soupçonne que la base de données a migré trop loin pour l’ancien conteneur.
Bonjour, même erreur ici. La solution de contournement pour le moment consiste à forcer le paramètre de version dans app.yml à v3.3.0. Arch AMD64, Ubuntu 18.04. Étrange qu’une version mineure ait échoué, la mise à jour vers v3.3.0 s’est déroulée sans problème la semaine dernière
Pour quiconque rencontre ce problème et est à l’aise pour me donner accès à son serveur, veuillez m’envoyer un message privé afin que je puisse déboguer le problème sur un serveur qui présente le problème. J’ai essayé plusieurs méthodes et je ne parviens pas à reproduire ce problème, ce qui rend plus difficile la mise en œuvre d’une solution.
Pour ceux qui sont bloqués avec ce problème de Discourse en panne, j’ai trouvé que vous pouvez au moins faire fonctionner l’ancienne version du forum en redémarrant la VM, puis en exécutant ./launcher start app. Cette commande ne fonctionnera pas après avoir tenté une reconstruction sans redémarrer votre instance / VM.
Je devrais pouvoir mettre à jour la version d’Ubuntu sur notre VM affectée lundi, donc je tiendrai tout le monde informé du résultat.
J’ai un autre forum sur une autre gouttelette et cela ne pose aucun problème de mise à jour. C’est étrange pourquoi avec la même configuration de serveur, une gouttelette a des problèmes alors qu’une autre n’en a pas ?
Cela ressemble à un problème de RAM. Quelle quantité de RAM et de swap avez-vous ? J’ajouterais un ou deux Go d’espace SWAP (et peut-être ajouter de la RAM si vous n’avez que 1 Go)
Quelle quantité de RAM et de swap avez-vous sur ces systèmes ? Quel est le résultat de
free -h
Et la RAM expliquerait pourquoi @tgxworld n’a pas pu le reproduire.
Je suis à peu près certain que le problème vient de la RAM/swap.
Au fait, pour tous ceux qui rencontrent ce problème, vous pouvez le contourner pour l’instant en ajoutant base_image: discourse/base:2.0.20240708-0023 en haut du fichier containers/app.yml.
Cela pourrait-il être un problème de taille de base de données ?
La base de données sur notre serveur de production est assez volumineuse, mais celle de développement est très petite. C’est la seule réelle différence entre les VM qui ont été mises à niveau avec succès et celle affectée (dans mon cas).
Bonjour,
Je viens d’agrandir mon Droplet en doublant la RAM et en augmentant la taille du disque. Je rencontre toujours le même problème.
Y a-t-il autre chose à essayer ?
OMG ! Pourquoi n’ai-je pas lu cette solution auparavant. Cela a également fonctionné pour moi.
Alors quelle est la solution pour l’avenir ? Devons-nous continuer à spécifier cette image de base à l’avenir ou la modifier pour obtenir une image mise à jour ?
