Ecco tutto quello che ho trovato
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Comando terminato con SIGKILL (Terminazione forzata): ember build -prod
Idee?
È durato troppo a lungo. Prova ad aumentare lo swap o la RAM.
Sono un po’ scettico. 8 GB di RAM, si è bloccato subito e non è mai successo niente del genere prima. Cosa si può cambiare in modo che la memoria non sia sufficiente oggi, ma lo fosse ieri e quando ho aggiornato il database 
Apprezzo il tuo scetticismo.
Questa è stata la soluzione quando ho riscontrato quell’errore. Una ricerca su Internet (molto) rapida dice lo stesso.
Lo proverò comunque, ovviamente. Aggiungere lo swap non è un lavoro così grande. Ma non riesco a capire perché sia successo 
Di solito grep /var/discourse/discourse-setup e copio/incollare la parte che crea lo swap.
Non capisco nemmeno io.
2-container e, quando ho prima fermato web_only e poi entrambi i container, è andato a buon fine. Quindi può essere davvero una mancanza di memoria.
30 anni fa la raccomandazione era di avere tanto swap quanto RAM. Non so quale sia la regola generale ora, ma penso che con 8 GB, aggiungerne 2 o anche 4 non sia una cattiva idea.
Ho aggiunto 2 gigabyte. Però non so perché sto cercando di risparmiare spazio su disco. Perché se mai dovessi trovarmi in una situazione in cui ho problemi perché mi mancano pochi gigabyte, avrei cose più importanti a cui pensare che alla dimensione dello swap.
1 Mi Piace
Ho appena rifatto il rebuild (contenitore 2) pochi minuti fa e ho ottenuto questo:
Ambiente: produzione
L'impostazione 'staticAddonTrees' diventerà true di default nella prossima versione di Embroider e non potrà più essere disattivata. Per prepararti a questo,
dovresti impostare 'staticAddonTrees: true' nel tuo file di configurazione di Embroider.
L'impostazione 'staticAddonTestSupportTrees' diventerà true di default nella prossima versione di Embroider e non potrà più essere disattivata. Per prepararti a questo,
dovresti impostare 'staticAddonTestSupportTrees: true' nel tuo file di configurazione di Embroider.
costruendo...
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Il comando è stato terminato con SIGKILL (Terminazione forzata): ember build -prod
Cosa bisogna fare ora?
Ho la sensazione di aver già visto questo.\n\nhttps://meta.discourse.org/t/rebuild-fails-with-exit-1-err-pnpm-recursive-exec-first-fail/351862\n\nAvevo 8 GB di RAM e lo swap era di 2 GB: di quanta ne ho davvero bisogno al giorno d’oggi, se questo deriva da una mancanza di memoria?
Beh, ho cambiato lo swap da 2G a 4G e la ricompilazione è andata a buon fine. Quindi forse era di nuovo una questione di quantità di RAM. O è stato un colpo di fortuna.
E poi torniamo all’argomento FAQ: quanta RAM necessita realmente Discourse — perché lo swapfile è di fatto parte della quantità totale di RAM, e ora sembra che il fabbisogno effettivo sia di 11+ GB per un piccolo forum 
1 Mi Piace
Hai impostato le due impostazioni del kernel? Influiranno sulla quantità di memoria virtuale necessaria.
Risponderei di no, perché non ho idea di cosa tu stia parlando 
Sono sicuro allora, non li hai impostati!
Purtroppo, modificare il kernel Linux non fa parte dell’installazione ufficiale di Discourse, ma la mia comprensione è che questi due semplici trucchi aiuteranno il tuo server a funzionare bene e a utilizzare meno memoria. Oppure, ovviamente, puoi farne a meno ma potresti scoprire di aver bisogno di più RAM+swap di quanto vorresti.
Vedi MKJ’s Opinionated Discourse Deployment Configuration se desideri altri suggerimenti.
Ciò era dovuto a una particolare caratteristica del vecchio codice di gestione della memoria e non si applica più a Linux oggi. Ora non c’è una vera regola generale; si tratta solo di quanto ne hai bisogno.
2 Mi Piace
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.