C’est tout ce que j’ai trouvé
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod
Des idées ?
Il a fonctionné trop longtemps. Essayez d’augmenter le swap ou la RAM.
Je suis un peu sceptique. 8 Go de RAM, ça a planté tout de suite et quelque chose comme ça ne s’est jamais produit auparavant. Qu’est-ce qui peut être changé pour que cette mémoire ne suffise pas aujourd’hui, mais suffisait avant-hier et lors de la mise à niveau de la base de données 
Je comprends votre scepticisme.
C’est ce qui a résolu le problème quand j’ai rencontré cette erreur. Une recherche rapide (très rapide) sur Internet dit la même chose.
J’essaierai quand même, bien sûr. Ajouter un swap n’est pas un travail si important. Mais je ne comprends pas pourquoi c’est arrivé 
Je peux habituellement utiliser grep /var/discourse/discourse-setup puis copier/coller la partie qui crée le swap.
Je ne comprends pas non plus.
2-conteneur, et lorsque j’ai d’abord arrêté web_only puis les deux conteneurs, cela a fonctionné. Il peut donc vraiment s’agir d’un manque de mémoire.
Il y a 30 ans, la recommandation était d’avoir autant de swap que de RAM. Je ne connais pas la règle empirique actuelle, mais je pense qu’avec 8 Go, en ajouter 2 ou même 4 n’est pas une mauvaise idée.
J’ai ajouté 2 Go. Je ne sais pas pourquoi j’essaie d’économiser de l’espace disque, cependant. Parce que si je me retrouve un jour dans une situation où j’ai des problèmes parce qu’il me manque quelques Go, j’aurai des choses plus importantes à penser que la taille de mon swap.
1 « J'aime »
Je viens de faire la reconstruction (2 conteneurs) il y a quelques minutes et j’ai obtenu ceci :
Environnement : production
Le paramètre 'staticAddonTrees' sera par défaut à true dans la prochaine version d'Embroider et ne pourra plus être désactivé. Pour vous préparer, vous devriez définir 'staticAddonTrees: true' dans votre configuration Embroider.
Le paramètre 'staticAddonTestSupportTrees' sera par défaut à true dans la prochaine version d'Embroider et ne pourra plus être désactivé. Pour vous préparer, vous devriez définir 'staticAddonTestSupportTrees: true' dans votre configuration Embroider.
Construction...
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL La commande a été tuée avec SIGKILL (terminaison forcée) : ember build -prod
Que faire ensuite ?
J’ai l’impression d’avoir déjà vu ça.
J’avais 8 Go de RAM et 2 Go de swap — de combien ai-je vraiment besoin de nos jours, si cela vient d’un manque de mémoire ?
Eh bien, j’ai changé le swap de 2G à 4G, et la reconstruction s’est déroulée. Donc, peut-être que c’était encore une question de quantité de RAM. Ou c’était un coup de chance.
Et puis nous revenons au sujet de la FAQ : combien de RAM Discourse a-t-il vraiment besoin — car le fichier swap fait de facto partie de la quantité totale de RAM, et maintenant il semble que le besoin réel soit de 11+ Go pour un petit forum 
1 « J'aime »
Avez-vous configuré les deux paramètres du noyau ? Ils affecteront la quantité de mémoire virtuelle nécessaire.
Je répondrais non, car je n’ai aucune idée de ce dont vous parlez 
Je suis sûr alors, vous ne les avez pas définis !
Malheureusement, modifier le noyau Linux ne fait pas partie de l’installation officielle de Discourse, mais je crois comprendre que ces deux astuces simples aideront votre serveur à fonctionner correctement et à utiliser moins de mémoire. Ou, bien sûr, vous pouvez vous en passer, mais vous pourriez constater que vous avez besoin de plus de RAM + de swap que vous ne le souhaiteriez.
Consultez MKJ’s Opinionated Discourse Deployment Configuration si vous souhaitez d’autres conseils.
C’était dû à une caractéristique particulière des anciens codes de gestion de mémoire, et cela ne s’applique pas à Linux aujourd’hui. Il n’y a plus de règle générale ; il s’agit simplement de savoir de combien vous avez besoin.
2 « J'aime »
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.