J’ai enfin une machine avec un peu de place pour faire tourner un nœud Duniter (il me semble que le réseau en a besoin). Vous avez peut-être vu passer g1.trentesaux.fr, mais celui-ci crash environ une minute après le lancement :
Par défaut la variable NODE_OPTIONS n’est pas set, et j’ai essayé de la mettre à 6Go avec export NODE_OPTIONS="--max-old-space-size=6144" mais ça ne change rien. De plus, htop ne montre pas d’utilisation abusive de mémoire (<2Go)
Rencontres-tu ce problème avec la v1.8.1 ?
Pour s’assuser que rien d’autre n’a changé entre-temps.
Beaucoup de temps s’est écoulé entre les deux releases. Peut-être une version mineure de Nodejs change la donne ?
Autrement, si tu n’observes pas de saturation de la mémoire vive lors du démarrage, ça ne va pas être simple à débugger.
Peux-tu nous donner un peu plus de contexte. ARM ? Combien de RAM disponible ? Debian ? Quelle version de Debian ? Peut-être que Nodejs intégré n’est pas compatible.
Pour le contexte, c’est assez basique : debian bullseye x86_64, 12Go de ram, j’ai tué mes autres services pour être sûr d’avoir toute la ram dispo pour Duniter.
Il faut que j’essaye les versions antérieures, je vais aussi essayer une compilation manuelle et changer de version de nodejs. Pour l’instant j’ai
edit: non pertinent
$ apt info nodejs
Package: nodejs
Version: 12.22.5~dfsg-2~11u1
(d’ailleurs je ne sais pas comment nodejs s’est retrouvé installé, je ne l’ai pas fait il me semble)
$ /opt/duniter/node/bin/node --version
v10.20.1
Mais ça m’arrangerait que quelqu’un ait rencontré le même problème, je préférerais consacrer le peu de temps que j’ai pour me mettre à jour avec Duniter-v2s et Ğecko-v2s. Donc je vais attendre un peu avant de faire les tests.
La dernière fois que j’ai vu cette ligne, c’est parce que j’avais installé la version x86_64 sur une architecture ARM. Ça n’a sans doute aucun rapport avec ton problème, mais je le dis à tout hasard.
J’ai observé que l’ajout de gros blocs fait crashé Duniter.
Tu peux remédier à ça avec un contournement avec le système d’initialisation.
Dans le cas de systemd :
Restart=on-failure
Il redémarre et ajoute le bloc qui l’a tué comme un grand.
Il suffit de chercher dans les logs une ligne de démarrage pour observer ce comportement
Je n’ai pas mis de restart on failure, je préfère faire manuellement, ça me donne une idée de la fréquence à laquelle ça crashe et ça avertit les utilisateurs que mon nœud n’est pas dans des conditions très fiables
Cette fois-ci, ça a l’air d’être un plantage plus intéressant :
2023-06-04T19:14:16+02:00 - info: Block resolution: 1 potential blocks after current#632434...
2023-06-04T19:14:18+02:00 - info: WS2P: init: bundle of peers 1/10
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - error: Unhandled rejection: [object Object]
2023-06-04T19:14:18+02:00 - error: httpCode=400, ucode=1015, message=Document already under treatment
2023-06-04T19:14:19+02:00 - info: Block #632435 added to the blockchain in 1144 ms
2023-06-04T19:14:19+02:00 - debug: Opening SQLite database "/home/hugo/.config/duniter/duniter_default/wotwizard-export_0.db"...
2023-06-04T19:14:19+02:00 - error: Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed
at ChildProcess.target.send (internal/child_process.js:636:16)
at Worker.send (internal/cluster/worker.js:40:28)
at PowWorker.sendCancel (/opt/duniter/app/modules/prover/lib/PowWorker.js:81:27)
at slaves.forEach (/opt/duniter/app/modules/prover/lib/powCluster.js:121:22)
at Array.forEach (<anonymous>)
at Master.cancelWorkersWork (/opt/duniter/app/modules/prover/lib/powCluster.js:120:21)
at Master.cancelWork (/opt/duniter/app/modules/prover/lib/powCluster.js:130:14)
at PowEngine.cancel (/opt/duniter/app/modules/prover/lib/engine.js:43:29)
at WorkerFarm.stopPoW (/opt/duniter/app/modules/prover/lib/blockProver.js:70:53)
at BlockProver.cancel (/opt/duniter/app/modules/prover/lib/blockProver.js:122:24)
Aucune erreur ne peut exclure un manque de mémoire, puisque les effets sont imprévisibles, comme par exemple empêcher l’ouverture de fichiers, tuer des processus ou refuser des allocations.