Celle-ci est susceptible de fonctionner. Vous pouvez démarrer cette image avec par exemple docker start b5f2a8a39709.
(Vous pourriez aussi vouloir supprimer certaines de ces anciennes images - il y a potentiellement une grande quantité d’espace disque qui peut être récupérée !)
Obtention : Réponse d’erreur du démon : Aucun conteneur : b5f2a8a39709
Merci. De plus, mes procédures de sauvegarde copient TOUS les fichiers du système. Il y a probablement des images plus récentes là-bas si je savais où chercher et où les copier.
Mes excuses pour cette interruption du contournement, mais nous allons migrer vers un autre serveur, ce qui a été un défi en soi car il s’agissait d’un serveur dédié et nous avons renouvelé le contrat pour une année entière en juin dernier.
Peut-être serait-il bon que l’équipe Discourse émette un avertissement pour les personnes qui l’exécutent sur des serveurs qui ne sont plus pris en charge. Le découvrir comme nous l’avons fait est TRÈS désagréable. (trois utilisateurs avec le même problème, nous parlons de serveurs, ils ne sont pas renouvelés aussi rapidement que les ordinateurs portables.)
Je tiens à préciser que ce n’était pas un changement intentionnel.
Nous n’avons pas non plus d’accès direct à du matériel aussi ancien et devons nous fier à l’aide de la communauté ici pour déterminer exactement ce qui ne va pas.
Une fois que nous saurons avec certitude qu’il s’agit d’un problème de compilation avec le gem lui-même, nous pourrons agir.
@ici
L’ajout d’une clé de niveau supérieur dans le fichier app.yml avec
base_image: discourse/base:2.0.20220621-0049-slim
devrait contourner le problème, bien que cela ralentisse un peu les reconstructions.
C’est juste, mais de tels serveurs sont toujours proposés par des fournisseurs du monde entier comme serveurs d’entrée de gamme.
Pour de nombreux petits projets Open source, de tels serveurs sont idéaux, en termes de prix, et souvent ils n’ont pas les moyens d’avoir un Intel Xeon ou un AMD Ryzen avec 32 Go de RAM.
Je comprends tout à fait que vous n’ayez pas le matériel pour tester le logiciel, mais d’après la communication dans ce fil, cela a été établi par nous et il n’y a eu aucune réaction par la suite.
Un simple désolé, nous allons examiner cela aurait suffi dans ce cas, au lieu de cela, vous nous avez laissé en plan.
Test en cours avec cette modification.
La compilation semble échouer de la même manière.
Ceci a été fait avec la modification de containers/app.yml, en ajoutant :
base_image: discourse/base:2.0.20220621-0049-slim
vers le haut.
Cela signifie que le problème n’est pas que nous livrons une version précompilée du gem, mais que le gem en amont ne peut pas compiler sur ces anciens processeurs.
Nous avons ouvert le problème #789 contre le gem oj.
Compris. J’aimerais restaurer une de mes images Docker récentes – à partir de mes sauvegardes rsync. Y a-t-il une procédure que vous pouvez me montrer pour les localiser et en restaurer/démarrer une ? Merci !
Avez-vous essayé un ./launcher start app ?
Si celui-ci ne fonctionne pas, essayez l’autre méthode que j’ai détaillée pour reconstruire à partir du dernier commit fonctionnel.
Oui. Cela lance le serveur web, mais vous ne pouvez pas accéder aux threads, ils tournent juste.
Cela n’aidera pas.
Le problème est que le gem mis à jour ne vérifie pas si l’instruction est prise en charge par le CPU avant de l’utiliser.
Cela aidera à remettre l’instance Discourse en marche car elle installe la version précédente/fonctionnelle du gem (prouvé par ce que j’ai fait pour remettre l’instance de Bryan en marche), mais oui - toute autre mise à jour (via admin/upgrade) déclenchera le même problème à nouveau.
Je n’ai pas de succès avec une nouvelle compilation ni avec le lancement de l’instance précédente, donc comme le week-end approche, je vais peut-être attendre la semaine prochaine en espérant que la situation puisse être résolue du côté du gem …
De quelle procédure s’agissait-il ? Je suis, je l’avoue, un peu confus maintenant en essayant de suivre les différentes idées sur ce fil de discussion. Merci !
La deuxième partie de ce message :
Je vais essayer. Merci.
Une autre solution de contournement possible consiste à ajouter ce qui suit à app.yml
hooks:
after_code:
- exec:
cmd:
- sed -i -e 's/oj (3.13.*/oj (3.13.14)/' Gemfile.lock
Je suppose que les mises à jour seraient toujours dangereuses après cela, n’est-ce pas ? Je suis en train de faire la compilation sur le commit précédent.