https://g1.cgeek.fr/blockchain/block/898773 par exemple
Pour le dernier block connu partout, le 898728, on a exactement les mêmes hash (ou peut-être qu’il faut regarder des autres données dans le block).
La query exécutée sur les mêmes 2 noeuds 1.8.7 et 2 noeuds 1.9.0 (bloqués):
Je ne peux pas comparer le suivant (898729) vu qu’il n’existe pas sur ces 4 noeuds 1.9.0.
Donc pas de fork, probablement plutôt un problème de connectivité inter-noeuds.
Il est possible de regarder sur la webui de son nœud, voici ce qu’affiche le mien à l’instant :
Effectivement 898728 paraît très éloigné (13h de retard).
Pas “13h”
, le 898728 était ce matin vers 10h04 quand j’ai regardé (sur les noeuds 1.8.7) pour la première capture d’écran Kazou.
Et voici la vue “réseau” depuis mon noeud désynchronisé (bloqué sur 898728):
Je viens de regarder dans les logs du serveur, et en cherchant pour les mentions du dernier block en question (+1 pour avoir celui qui ne passe pas = 898729); je retrouve des messages d’erreurs qui reviennent tout le temps, et avec comme variante le nombre de “Fork resolution: 85 potential block(s) found” qui augmente au fur et à mesure:
docker compose logs -n 2000 | grep -B5 -A5 "898729" | less
>
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Blocks were not applied. │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Blocks were not applied. │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Block resolution: 2 potential blocks after current#898728... │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - error: Error: ruleNumber │
│duniter-v1-1.9.0 | at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19) │
│duniter-v1-1.9.0 | at process._tickCallback (internal/process/next_tick.js:68:7) │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - error: Error: ruleNumber │
│duniter-v1-1.9.0 | at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19) │
│duniter-v1-1.9.0 | at process._tickCallback (internal/process/next_tick.js:68:7) │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Fork resolution: 85 potential block(s) found... │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Fork resolution: block #898729-0000001D is known as incorrect. Skipping. │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Fork resolution: block #898729-0000001D is known as incorrect. Skipping. │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Fork resolution: block #898729-0000001D is known as incorrect. Skipping. │
│duniter-v1-1.9.0 | 2026-01-13T15:31:39+00:00 - info: Fork resolution: block #898729-0000001D is known as incorrect. Skipping.
Ah, bien
mais mauvaise nouvelle alors, ces noeuds restent bloqués.
Avec les conseils de Pini j’ai restart mon serveur 1.9.0, il m’a fait une belle erreur après avoir récupérer les blocks de retard:
duniter-v1-1.9.0 | 2026-01-13T17:58:00+00:00 - info: Block #898837 added to the blockchain in 210 ms
duniter-v1-1.9.0 | 2026-01-13T17:58:00+00:00 - info: Fork resolution: suite 1/3 added block#898837-00000006004E44E2A644E7BD202961828FF22DA85B9B9796D663CBEB2B940659
duniter-v1-1.9.0 | 2026-01-13T17:58:01+00:00 - info: Block #898838 added to the blockchain in 144 ms
duniter-v1-1.9.0 | 2026-01-13T17:58:01+00:00 - info: Fork resolution: suite 1/3 added block#898838-00000001663B7CDC8A67C59A9B4E857FBF5095F2E83447D64E9D8D8A665D56CA
duniter-v1-1.9.0 | 2026-01-13T17:58:01+00:00 - info: Fork resolution: suite 1/3 reached HEAD + 77. Now rolling back.
duniter-v1-1.9.0 | 2026-01-13T17:58:05+00:00 - error: Error: DB corrupted:Not found origin tx of uxto 1954F995A0521F658E3864956B672890F2D6375AE59E2D40C19ADBAB366EA2D6:0
duniter-v1-1.9.0 | at Function.revertBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:382:28)
duniter-v1-1.9.0 | at BlockchainContext.revertCurrentBlock (/duniter/app/lib/computation/BlockchainContext.js:110:53)
duniter-v1-1.9.0 exited with code 1 (restarting)
Mais après ce 2ème redémarrage; il semble être de nouveau synchronisé ![]()
Je crois que c’est @Moul qui a remarqué cela, aussi.
Bien content de voir que mes backups sont utiles ![]()
Mais par curiosité : Tu as toi aussi des backups pour cette version. As-tu tenté de redémarrer à partir d’un backup de la veille ?
J’avoue que je ne pensais pas que je pourrais récupérer mon noeud avec mon propre backup, je n’ai pas testé; après, c’était très probablement plus éfficace avec un backup plus récent d’un serveur qui était toujours fonctionnel ![]()
J’avais réussi il y a quelque temps à récupérer mon noeud avec un backup de @daigongen (je crois) qui datait de plusieurs jours. Donc je pense que c’est faisable de tenter de repartir d’un de ses propres backups pas trop ancien.
Tu as raison sur l’efficacité d’un backup plus récent. J’étais juste curieux de savoir si tu avais tenté.
Je suis parti de ton backup de ce matin Nicolas.
Il m’a fallu plusieurs redémarrages avant qu’il reste synchronisé étant donné qu’il ne semblait pas connecté au réseau via WS2P info: WS2P: connected to peer. Mon nœud n’a pas les connexions entrantes de configuré, du coup, difficile à maintenir la connexion avec le reste du réseau.
Mon noeud 1.9.0 ainsi que 2 autres sont encore reparti en fork au block 898934… ![]()
Ce coup-ci, un simple redémarrage ne semble pas fonctionner - il refait la même erreur en boucle:
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - info: Block resolution: 0 potential blocks after current#898935...
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - info: Fork resolution: 65 potential block(s) found...
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - info: Fork resolution: 1 potential suite(s) found...
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - info: Fork resolution: HEAD = block#898935
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - info: Fork resolution: suite 1/1 (-> #899003-000000) revert to fork point block#898934
duniter-v1-1.9.0 | 2026-01-14T08:06:41+00:00 - error: Error: db corrupted: not found consumed utxos UtxoIdDbV2(Hash(2FB14205298948C5E5510A980F0EBD5A7CFD0D1A9D395944B294D17BD7FB0B51), 1)
duniter-v1-1.9.0 | at Function.revertBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:382:28)
duniter-v1-1.9.0 | at BlockchainContext.revertCurrentBlock (/duniter/app/lib/computation/BlockchainContext.js:110:53)
duniter-v1-1.9.0 exited with code 1 (restarting)
J’ai resynchronisé les noeuds g1.asycn.io et duniter-g1-v1.axiom-team.fr vers 00h30, ils étaient encore synchros vers 3h mais sont désormais bloqués sur ce bloc 898934 eux aussi.
@Pini Je viens d’arriver à réparer mon noeud en repartant de mon propre backup d’hier (donc c’est faisable avec le backup du noeud lui-même) ![]()
Par contre, combien de temps ça va tenir ![]()
Reprends à partir d’un export.
Je n’ai compris que récemment que l’accès WS2P entrant est vital pour la stabilité du réseau. Cette info est cachée dans la doc pas du tout au même endroit que la conf WS2P :
Note sur le WS2P public (recommandé)
Il faut nécessairement des nœuds avec ws2p public pour que le réseau duniter fonctionne, et plus il y a de nœuds avec ws2p public, plus le réseau est décentralisé.
Ce mode est facultatif ne serait-ce parce que techniquement il est parfois difficile, voire impossible d’être accessible par l’extérieur (nœud derrière un routeur 4G par exemple).
Salut,
Je ne sais pas si mon signalement vient au bon endroit; ce samedi soir 17/01/2016, Cesium V1 apparaît incapable de détecter une liste de nœuds actifs ![]()
Salut,
Je ne sais pas si mon signalement vient au bon endroit; ce samedi soir 17/01/2016, Cesium V1 apparaît incapable de détecter une liste de nœuds actifs
@philenvie59 Pour le moment la majorité des serveurs sont synchronisés, mais je suppose que c’est parfois possible que les quelques serveurs désynchronisés posent problème lors d’une connection avec Cesium v1.
Une fois qu’une première connection est établie, tu peux également forcer ton application à se connecter sur un serveur en particulier (un qui est peut-être plus stable que d’autres).
Pour voir la liste des serveurs v1 et leur status:
Depuis ± 10h40 nous avons de nouveau 2 noeuds 1.9.0 qui sont bloqués (sur block 900123), le mien et celui de @Pini.
J’ai tenté des redémarrage, ce n’est pas passé.
J’ai du ré-appliquer un backup pour le rétablir.
Accessoirement, est-ce que l’on connait les personnes qui administrent les noeuds restants qui sont en ligne et désynchronisés ?
Ce serais top si on pouvait leur demander de les réparer ou au pire, de les couper.
Voici les serveurs qui restent désynchronisés depuis un petit moment (en reprennant les données de Kazou):
- Bloqué sur block 898934
- g1.asycn.io:443 898934 BMAS 53 1.9.0 Non ???
- duniter-v1-g1.axiom-team.fr:443 898934 BMAS 200 1.9.0 poka @poka
- Bloqué sur block 892728
- duniter-v1.comunes.net:443 892728 BMAS 189 1.9.0 vjrj @vjrj
- Bloqué sur block 879449
- g1.e-is.pro:443 879449 BMAS 106 1.8.7 BenoitLavenier @Benoit_Lavenier
J’ai vu ça ce matin aussi. Je viens de relancer à partir de mon dernier backup.
Plus que 7 semaines ![]()


