La commande est celle-ci, le block number désigne le bloc de fin je crois.
duniter sync DUNITER_NODE_HOST [BLOCK_NUMBER]
Si tu laisse 443, alors la synchro stoppe au bloc 443 (de mémoire).
3 Likes
ça expliquerait tout.
En passant, mon raspi 4 est du coup synchro à 97% en 45min. C’est pas la même en effet. Je croise les doigts.
Edit : synchro effectuée sur raspi 4 en 1h exactement!
2 Likes
J’ai resynchronisé mon noeud également, il semble par contre qu’il n’y ait pas eu de DU depuis le 2 janvier. Vous constatez aussi ça ou c’est mon cesium qui bugge (déjà observé).
++
Le plus simple est d’utiliser la commande screen qui permet de faire tourner un shell en arrière plan.
Par exemple :
screen -S duniter
Tu te retrouves alors dans une session screen et tu lances les commandes que tu veux, comme ./resync.sh ; ./watchit.sh
Quand tu as fini de lancer les commandes que tu voulais et que ton process tourne, tu fais [Ctrl]-A-D pour te détacher de screen. La session screen continue à tourner dans son coin, et toi tu te retrouves dans ton shell d’origine.
Tu peux alors regarder quelles sont les sessions screen qui tournent en faisant screen -ls.
Et là, tu peux te délogger, ça continue à tourner dans la session screen qui est maintenant détachée de ton shell. Quand tu reviens quelques heures/jours/mois plus tard, tu peux te rebrancher sur la session screen en faisant :
screen -r duniter
Et si tu veux que la session screen s’arrête pour de bon, il suffit de faire [Ctrl]-d comme pour faire un exit d’une session shell. C’est quand même bien foutu ! 
5 Likes
merci, merci beaucoup. C’est trop cool!
J’ai jamais réussi à comprendre comment est installé ce nœud et comment le resynchroniser.
Aussi, Remuniter est resté bloqué.
1 Like
Oh bor**l.
Du coup j’ai pu synchroniser aujourd’hui.
Cela dit, j’avais essayé plusieurs fois depuis duniter-desktop sans succès.
Est-ce que si il y a un micro-coupure du réseau, ça fait planter la synchronisation ? Ces deux derniers jours me laissent une impression de “fragilité” de Duniter. Je comprends qu’il y a eu un bug, on ne peut pas se prémunir de tous les imprévus.
Je comprends pas bien pourquoi la résolution de fork a coincé. Est-ce qu’on a une explication ? Je ne sais pas si @cgeek a déjà pu se pencher dessus ou si d’autres ont regardé ?
Et je reste vraiment surpris d’avoir du faire 10-15 essais pour réussir une synchronisation (beaucoup d’essais depuis duniter-desktop, des essais depuis duniter-server en mode graphique sur 127.0.0.1:9220 et des essais en console…). J’aimerais comprendre pourquoi ça a été si compliqué cette fois pour avoir à nouveau un nœud fonctionnel.
Le fork n’a pas pu être résolus car GerardSiegle devait être exclu car n’ayant que quatre certifications. Le rollback était bloqué à cause de ce problème. Problème causé par le fait qu’il soit entré avec quatre certifications. Là, ça nous dépasse, à cgeek de trouver la raison de ce bug.
Pour les problèmes de synchronisation je sais pas. Il faut ouvrir un ticket avec les logs d’erreur.
resync de g1.duniter.org en cours.
5 Likes
Je regarde, mais clairement il y a un bug derrière car l’état n’est pas cohérent selon qu’on reçoit le bloc la 1ère fois où qu’on l’interprète dans le cadre d’une résolution de fork.
Pour le coup c’est bien ce bug là qui est derrière le fork.
2 Likes
Si tu fais un “post-mortem”, ça m’intéresse vraiment d’en savoir plus. 
Je vais bien entendu révéler le bug dès que je l’aurais débusqué, puis verrouiller le comportement avec un test automatisé qui solutionnera à jamais ce problème.
Duniter peut paraître « fragile » à certains égards, mais il faut savoir que la partie fonctionnelle du programme (= le respect du protocole) est balisée par 700 tests automatisés. C’est la seule et unique raison qui fait que la Ğ1 tient autant la route malgré l’absence de développeurs depuis 2 ans.
Bref, oui, tu vas tout savoir bientôt.
3 Likes
Je voudrais préciser quelque chose : À aucun moment je ne doute du fait que chacun fait de son mieux pour que tout fonctionne et soit le plus solide et résilient possible. Et je sais qu’on ne pourra jamais éviter tous les bugs. Donc, c’est important, je ne te remets pas en cause. (Et j’espère que ça n’a pas été commpris comme tel ! 
)
Ce que je me rends compte, c’est qu’il manque d’autres personnes capables de se pencher sur le code de duniter (le programme). Mais je pense que tu es parfaitement conscient du problème.
Un de mes objectif cette année est de monter en compétences sur tout ça mais n’ayant pas touché vraiment du code depuis longtemps, je pars de loin. 
1 Like
Je ne le prends pas personnellement ne t’inquiètes pas.
Du reste, il va falloir attendre quelques jours pour que je découvre la cause du problème.
Et bien mauvaise nouvelle : impossible de resync le noeud g1.duniter.org. Il reste bloqué sur le block 285387. J’éteins le noeud en attendant, pour éviter que les utilisateurs envoient leurs document sur un noeud désynchro.
As-tu eu le temps d’essayer plusieurs fois ? J’ai du faire pas mal d’essais pour que ça finisse par passer… Finalement j’ai pu synchroniser depuis le nœud duniter.moul.re.
@cgeek, je suppose que tu es au courant, mais au cas où, j’ai bien l’impression que Remuniter aussi est resté coincé sur le bloc #285383-000004E92CD3.
Enfin… c’est ce qu’affiche le site https://remuniter.cgeek.fr/#/
J’ai fait des petits scripts qui relancent automatiquement la synchro en cas d’échec, car avec mon raspi je tombe souvent sur ce cas-là. À télécharger là : Jean-Yves / scripts-for-duniter · GitLab
Si je ne me trompe pas, Remuniter se connecte sur g1.duniter.org qui est actuellement bloqué, comme @Inso le signale un peu plus haut. C’est donc “normal” (ou en tout cas identifié).
Bon à savoir, merci @jytou !
Quand les synchros plantent, est-ce possible que ça soit parce que “le réseau de nœuds” galère ou est surchargé ? Je me demande juste si on risque pas de faire pire en essayant tous de se synchroniser en boucle ?
Remuniter est un nœud spécialisé. Il est donc avant tout un nœud en plus du module Remuniter.
Donc, il faut le resynchroniser.
1 Like