Bonjour,
je vais sur mon Cesium 1.7.16 et quand j’affiche la liste des nœuds
Serait-il envisageable de tenir jusqu’au 08.03.26 (ou fin février 2026 ou janvier 2026 ?)
indique aussi très peu de nœuds et les junistes se posent bcp de questions ! Que leur dire ? Les ĞMarchés de Noël sont là ! Un cadeau de Noël aux junistes ?
Merci pour votre réponse 
Il a du y avoir un fork, je regarderai demain pour ma part.
Effectivement, je vois seulement 4 nœuds synchro et le reste désynchronisés 
Je resynchronise mon nœud depuis g1.brussels.ovh (Nicolas80) qui est bien placé dans les trois outils. Je fais aussi les nœuds g1.duniter.org, Remuniter, WotWizard.
D’autres que moi sont concernés par ce fork, pourriez-vous resynchroniser votre nœud à la même adresse ? @Frederic_Renault @joss.rendall @Pini @HugoTrentesaux @vjrj
Il y a également le nœud miroir g1.e-is.pro @kimamila et le nœud AxiomTeam (@poka ?)
Kazou :
Ğinspecte :
Cesium :
Tentez en premier un redémarrage du nœud avant de vous lancer dans une nouvelle synchronisation pénible. Pour ma part, après un redémarrage de mon ordi, mon nœud s’est resynchronisé tout seul sur la branche majoritaire hier soir, sans que j’eusse connaissance qu’il y avait un fork. Avant ça, j’avais vu dans les logs beaucoup d’erreurs ruleMembershipPeriod.
effectivement, je n’arrive pas a rejoindre les bons blocs après plusieurs redemarrages depuis 6h ce matin, Merci @cgeek de ta direction, je change mon compose pour forcer la synchro sur Brussels
Pas simple : mon nœud reforke immédiatement après la synchro et se perd sur ce fork.
Je tente une resynchro avec l’option --forksize 0 afin de geler mon nœud sur cette branche, mais chaque synchro dure 3 heures.
Ok je viens de supprimer le dossier duniter data et lancer cette commande sur la noeud axiom-team:
NODE_OPTIONS=--max-old-space-size=10192 duniter sync --forksize 0 g1.brussels.ovh:443 && duniter start
Ca crash toujours à 10/11% de apply, j’ai essayé 3 fois:
Progress:
Milestones: [||||||||||||||||||||] 100 %
Download: [|| ] 12 %
Apply: [|| ] 11 %
Sandbox: [ ] 0 %
Peers: [ ] 0 %
Status: Peers...Complété
axiom@duniter-v1-data:~$
Bonjour
pareil pour moi depuis hier duniter en synchro
Posté hier sur télégram fork et les noeuds encore OK
il me faut + de 24h pour une synchro et oui c’est super long , ca devrait etre ok dans quelques heures
2025-12-02T11:24:34-04:00 - info: Milestones 100%, Downloaded 91%, Applied 89%
2025-12-02T11:31:05-04:00 - info: Milestones 100%, Downloaded 91%, Applied 90%
2025-12-02T12:09:57-04:00 - info: Milestones 100%, Downloaded 91%, Applied 91%
2025-12-02T12:13:25-04:00 - info: Milestones 100%, Downloaded 92%, Applied 91%
sauf si .. mais bon tout va bien aller
j aurais peut etre du restart duniter ou reboot mais pas pensé quand je vois dans les logs “block invalid skipping” genre c’est mauvais signe 
peut etre serait bien de resync/ arreter les noeuds qui moulinent sur une branche invalide et entre autre ceux définis par défaut sur les clients
*g1.duniter.org
*g1.e-is.pro
*g1.astroport.com
*duniter.econolib.re
Tu peux mettre aussi --nointeractive pour avoir le détail des logs.
oui je l ai lancé avec cette commande mais comme je n etais pas chez moi si et quand je vais deconnecter la session ssh en train de sync cela stop le process , alors je lance dans screen cela garde la console ouverte sur le serveur
“Screen is a terminal multiplexer for Linux that allows users to create and manage multiple terminal sessions within a single window. It is particularly useful for running long processes or maintaining sessions even after disconnecting from a remote server”
me suis fait avoir avec ca 2 ou 3 fois du coup magic screen
bon maintenant je ne sais et n’ose pas trop aller bidouiller pour afficher le process au risque de le stopper du coup oui j ai pas le détail
Ça fait une semaine que je galère à resynchroniser mes noeuds. Encore une synchro en cours actuellement. On fait ce qu’on peut…
À noter que dans les logs des noeuds j’ai beaucoup (beaucoup !) de noeuds pairs qui sont en timeout sur WS2P. Je pense qu’il y a un lien.
2025-12-02T08:21:41+00:00 - info: WS2P: init: bundle of peers 1/4
2025-12-02T08:21:56+00:00 - info: WS2P: Could not connect to peer 2ny7YAdm using `WS2P 82.65.206.220 20900: WS2P connection timeout`
2025-12-02T08:21:56+00:00 - info: WS2P: Could not connect to peer FBfxjqPH using `WS2P 90.22.71.45 20900: WS2P connection timeout`
2025-12-02T08:21:56+00:00 - info: WS2P: Could not connect to peer DomAF8Qy using `WS2P duniter971.dynssl.com 443: WS2P connection timeout`
2025-12-02T08:21:56+00:00 - info: WS2P: Could not connect to peer GfKERHnJ using `WS2P g1.moul.re 10900: WS2P connection timeout`
2025-12-02T08:21:56+00:00 - info: WS2P: Could not connect to peer fEPfZt2G using `WS2P 83.53.51.187 20902: WS2P connection timeout`
2025-12-02T08:21:56+00:00 - info: WS2P: init: bundle of peers 2/4
2025-12-02T08:22:11+00:00 - info: WS2P: Could not connect to peer 4bibsssD using `WS2P g1.asycn.io 443: WS2P connection timeout`
2025-12-02T08:22:11+00:00 - info: WS2P: Could not connect to peer 33wEa1Sg using `WS2P g1.madeirawonders.com 443: WS2P connection timeout`
2025-12-02T08:22:11+00:00 - info: WS2P: Could not connect to peer A5DdXxCK using `WS2P cuates.g1.casa 443: WS2P connection timeout`
2025-12-02T08:22:11+00:00 - info: WS2P: Could not connect to peer 6DrGg8cf using `WS2P duniter-v1.comunes.net 443: WS2P connection timeout`
2025-12-02T08:22:11+00:00 - info: WS2P: Could not connect to peer 55oM6F9Z using `WS2P g1v1.coinduf.eu 443: WS2P connection timeout`
2025-12-02T08:22:11+00:00 - info: WS2P: init: bundle of peers 3/4
2025-12-02T08:22:26+00:00 - info: WS2P: Could not connect to peer 5od17N1y using `WS2P g1v1.taeksheald.fr 22222: WS2P connection timeout`
2025-12-02T08:22:26+00:00 - info: WS2P: Could not connect to peer 7bmwxTBx using `WS2P gibraleon.g1.casa 443: WS2P connection timeout`
2025-12-02T08:22:26+00:00 - info: WS2P: Could not connect to peer ndYUMsDJ using `WS2P fania.g1.casa 443: WS2P connection timeout`
2025-12-02T08:22:26+00:00 - info: WS2P: Could not connect to peer CRBxCJrT using `WS2P 88.164.69.163 20900: WS2P connection timeout`
2025-12-02T08:22:26+00:00 - info: WS2P: Could not connect to peer FxjjjgcL using `WS2P v1.g1.rendall.fr 443: WS2P connection timeout`
2025-12-02T08:22:26+00:00 - info: WS2P: init: bundle of peers 4/4
2025-12-02T08:22:26+00:00 - info: WS2P: connected to peer 573v8LGa using `WS2P duniter-v1-g1.axiom-team.fr 443`!
2025-12-02T08:22:26+00:00 - info: WS2P: connected to peer GGdW5Rxd using `WS2P ws2p.nodo5.red-g1.ovh 443`!
2025-12-02T08:22:26+00:00 - info: WS2P: connected to peer C3oqFogS using `WS2P g1.duniter.org 443`!
2025-12-02T08:22:26+00:00 - info: WS2P: connected to peer FpAi3xR2 using `WS2P duniter.ganut.fr 443`!
@Nicolas80 je me demande s’il serait pertinant de configurer ton serveur pour refuser toute connexions sauf depuis les serveurs de @Pini @cgeek @joss.rendall @poka (bref, les noeud down qui essaient de se resyncro) pour éviter les blockage par timeout (et/ou de whitelister les requêtes depuis ces machines pour éviter que les quota anti DoS empèche la resync si tout le monde essai de la faire en même temps).
C’est dans la même idée que sur la V2 ou les nœuds forgerons ne sont pas exposés aux requêtes utilisateurs, seulement les nœuds miroirs le sont.
L’inconvénient c’est que ça rend moins accessible un des rares noeuds encore fonctionnel, donc ça n’est pertinant que si c’est effectivement une histoire de quota DoS qui génère les timeout et le blockage de re-sync.
Alternative : @Nicolas80 peux-tu faire une archive de ta DB et la mettre en ligne pour qu’elle puisse être importé par d’autres forgerons sans re-sync de 0 (si duniter-V1 est capable de ça, qu’en penses-tu @cgeek ?)
Synchro terminée et je me retrouve à nouveau immédiatement avec un fork insoluble :
2025-12-02T19:50:58+00:00 - info: WS2P: init: bundle of peers 3/3
2025-12-02T19:50:58+00:00 - info: WS2P: connected to peer CRBxCJrT using `WS2P 88.164.69.163 20900`!
2025-12-02T19:50:58+00:00 - info: WS2P: connected to peer C3oqFogS using `WS2P g1.duniter.org 443`!
2025-12-02T19:50:58+00:00 - info: WS2P: connected to peer GGdW5Rxd using `WS2P ws2p.nodo5.red-g1.ovh 443`!
2025-12-02T19:50:58+00:00 - info: Blocks were not applied.
2025-12-02T19:50:58+00:00 - info: Blocks were not applied.
2025-12-02T19:50:58+00:00 - info: Blocks were not applied.
2025-12-02T19:50:58+00:00 - info: Block resolution: 1 potential blocks after current#886503...
2025-12-02T19:51:00+00:00 - error: Error: ruleToBeKickedArePresent
at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:179:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
2025-12-02T19:51:00+00:00 - info: Fork resolution: 48 potential block(s) found...
2025-12-02T19:51:00+00:00 - info: Fork resolution: block #886504-0000000E is known as incorrect. Skipping.
2025-12-02T19:51:00+00:00 - info: Blocks were not applied.
2025-12-02T19:51:00+00:00 - info: Blocks were not applied.
2025-12-02T19:51:00+00:00 - info: Blocks were not applied.
2025-12-02T19:51:00+00:00 - info: Block resolution: 1 potential blocks after current#886503...
2025-12-02T19:51:02+00:00 - error: Error: ruleToBeKickedArePresent
at Function.checkBlock (/duniter/app/lib/blockchain/DuniterBlockchain.js:179:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
2025-12-02T19:51:02+00:00 - info: Fork resolution: 48 potential block(s) found...
2025-12-02T19:51:02+00:00 - info: Fork resolution: block #886504-0000000E is known as incorrect. Skipping.
C’est vraiment très très frustrant.
Pour ce dernier essai j’avais viré ma clef pour ne plus forger, voir si c’est ça qui mettait le bazar sur mon noeud. Mais apparemment non.
Je veux bien; mais pas sur ce la manière de faire cela sans risquer d’amener un soucis - est-ce que c’est dans la config du serveur V1 lui même ?
Si on m’explique comment le faire, je peux y regarder; mon serveur est dans un docker - en ARM64
Y’aurait pas moyen de relâcher un peu la valeur de timeout voir si ça change quelque chose ?
J’ai aussi galéré il y a quelques semaines pour synchroniser mon nœud (j’avais refait ma conf en changeant le fqdn et en remplaçant nginx par caddy).
Pour parvenir à synchroniser proprement, j’avais ajouté des nœuds privilégies et préférés :
duniter config --ws2p-prefered-add EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G
duniter config --ws2p-privileged-add EnFfLNWnonXwxmzipLbbqa1fybSs7xdPoYhmbkMYzR3G
J’avais constitué une liste d’une dizaine de nœuds qui semblaient ok dans cesium
ola 
suis en train de synchro sur g1.brussels
2025-12-02T16:10:53-04:00 - info: GOT chunk #3482/3546 from 870500 to 870749 on peer g1.brussels.ovh
duniter971.dynssl.com whitelist stp si tu bloques les connections entrantes siouplé
Je veux bien; mais pas sur ce la manière de faire cela sans risquer d’amener un soucis - est-ce que c’est dans la config du serveur V1 lui même ?
peut etre depuis le parefeu tu peux creer des régles pour refuser les noeuds desynchro?