Que ton noeud a deux fois la même fiche de pair (le contact d’un autre noeud). Rien de grave.
Ton noeud a tagé ce bloc comme faux. Ca arrive, et je crois qu’on ne sait pas encore vraiment pourquoi.
Ton noeud essaie de résoudre un fork et refuse d’ajouter le bloc 294631. De mon expérience :
soit ça se résout tout seul (attendre quelques heures)
soit il faut resynchroniser.
Je crois qu’il est possible de faire une resynchronisation partielle (en ligne de commande), mais je n’ai jamais réussi.
Ton noeud possède le bloc 294630.
Comme ça, je m’amuserais à faire :
duniter stop
duniter revert-to 294600 # on repart 30 blocs en arrière
duniter forward 294631 g1.duniter.org 443 g1.presles.fr 443 # on transmet le bloc en question pour le récupérer
duniter reapply-to 294631 # on re-applique jusqu'au bloc en question. Ou jusqu'à 294685, le bloc courant, si on veut.
duniter start
Mais pas sûr que ça marche, hein !
Sinon, essayer :
duniter stop
duniter revert-to 294600 # on repart 30 blocs en arrière
duniter sync g1.duniter.org
duniter start
… Pas sûr non plus que ça marche la résolution de fork à la main, c’est assez expérimental (ou mal documenté). Si tu trouves, ce serait chouette de poster la solution. Et oui, il faut être patient, et attendre de voir si ton noeud se resynchronise après chaque série de commandes, ce qui peut prendre plusieurs dizaines de minutes.
Aux expert.e.s :
Existe-t-il une commande pour forcer la re-vérification d’un bloc ?
J’ai vu que je pouvais faire une synchro partielle en ajoutant un chiffre à la fin de la commande sync, bon, je vais attendre en effet et voir si ça passe tout seul. Si je comprends bien, il faut attendre que ces deux clé (la mienne et celle qui coince) s’acceptent ? Bon je vais être patient pour l’instant. Je me demandais si il fallait essayer un gen-next ?
Merci @matograine , je tente, j’ai du repartir encore un peu avant du bloc 294550, je ne sais pas pourquoi il ne trouvait pas le bloc 294630 dans la db. Je vais tenter ta deuxième option. Ce n’est pas grave si j’avais utilisé une autre branche au départ pour synchroniser ?
Je crois que vous ne comprenez pas la différence noeud/branche.
La blockchain est un ensemble cohérent de documents (les blocs) qui se suivent. Tous les noeuds possèdent une copie de la blockchain. Cette copie est identique pour les noeuds à jour, sauf éventuellement à la fin.
Chaque noeud essaie d’ajouter un bloc à la Blockchain. S’il réussit, il publie ce bloc au reste du réseau. Lorsque deux noeuds trouvent un bloc en même temps, il y a un fork : la Blockchain se sépare en deux versions, qui diffèrent par les derniers blocs validés.
Avec le temps, une des branches va avancer plus vite que l’autre. A ce moment, les noeuds qui détectent cette différence d’avancée font une résolution de fork (c’est làque votre noeud plante) pour revenir à la branche qui a le plus avancé. En général, cela se résout en moins de 10 blocs.
Donc : tant que vous synchronisez votre noeud sur un noeud à jour, c’est bon. La branche et le noeud sont deux choses différentes.
Ça y est, s’est bien résolu ! Voici les commandes qui ont été salvatrices
$ duniter stop
$ duniter revert-to 294550 # j'ai dû aller un peu plus en arrière que ta proposition
$ duniter sync g1.duniter.org --slow # j'utilise l'option --slow car mon serveur n'est pas super puissant
$ duniter webstart # c'est cette commande qui marche pour démarrer ma version yunohost (peut-être car elle n'est pas reconnue par systemd ?)
Bonjour,
j’ai eu droit à une coupure de courant. Du coup avant de lancer Duniter, j’ai eu l’idée de relancer une synchronisation. Hier soir tard (j’ai dormi entre temps). Était-ce une bonne idée ? J’aurais pu peut-être juste redémarrer Duniter après qu’il ce soit arrêté une dizaines d’heures ?
Bref, la syncronisation n’est pas arrivée au bout. Cette fois c’était une erreur d’n bug connu apprement: ’ Error NO_NODE_FOUND_TO_DOWNLOAD_CHUNK #xxxx’ . J’ai bien vu l’issue à ce sujet…
Je relance de nouveau une synchro pour voir si je fini par arriver à redémarrer…
Autre question, je pas lancer de ‹ reset data › auparavant. Est-ce utile ?
Les nœuds rattrapent leur retard s’ils ont pas trop de retard. Un jour de retard c’est monnaie courante. Il y a pas mal de nœuds diurnes qui font ça. Je sais pas jusqu’où peut aller le rattrapage (via la synchro lente). Une semaine ? Faudrait essayer.
Il ya pas de limite, j’ai déjà rattrapé 2 mois en mode start, par contre c’est très long et pendant ce temps le noeud calcule la POW pour rien. Donc par soucis d’économie d’énergie c’est mieux de reset data and sync si le retard est grand.
@roodinux dans ton cas vu que ta sync a échoue c’est plus prudent de reset data et resync, sinon tu peut rester dans un état corrompu.
Salut, pour info, j’essaie pour voir si cela apporte une amélioration d’intégrer systemd avec la branche dev, est-ce que tu peux jeter un œil, savoir si je n’ai rien omis ?
Je vais essayer en test avec ynh_dev et vagrant avant de tout casser sur mon serveur…
Ok, après une nuit blanche pour installer yunohost en local avec ynh_dev et vagrant, j’ai pu installer ma modification. Là suis en train de faire une synchronisation. Question, est ce que je peux démarrer le serveur sans avoir au préalable lancer duniter wizard key ? J’imagine que même si ce n’est que pour un test, je ne peux pas avoir 2 noeuds duniter avec mon ID ?
Juste pour tester ? Ça m’a l’air de bien fonctionner pour l’instant, je pense que ensuite je pourrai lancer duniter start plutôt que duniter webstart ? ou bien sudo systemctl duniter start ?
Salut, ça m’a l’air de bien marcher, je suis presque tenter de tester sur mon serveur. Est-ce qu’il me suffit d’arrêter duniter et faire une mise à jour de duniter avec le lien de mon fork ou faudra-t-il plutôt désinstaller et réinstaller .? Qu’est-ce qui serait judicieux de regarder avec ce changement ?
Je me lance, par contre en effet, j’ai d’abord désinstaller duniter et réinstaller.
Bon je teste donc cette version de Duniter pour Yunohost. Cependant, je ne suis pas sûr d’avoir bien fait… J’ai gardé dans le PR de @Moul qui datait, où pour démarrer le noeud dans le script install , la commande était
# Launch Duniter node
service duniter start
au lieu de (dans la branche master)
# Launch Duniter node
duniter webstart
J’ai une confusion terrible entre duniter start et duniter webstart, mais je vois bien avec ce paquet yunohost que c’est webstart qui fonctionne. Du coup là en faisant fonctionner le noeud, j’ai ceci dans l’interface admin:
C’est bizarre que ce satut Acticating et le bouton Démarrer allors qu’il est bien démarrer:
$ duniter status
Duniter is running using PID 11665
Du coup je me demande si je ne devrait pas laisser duniter webstart dans le script install ?? Est-ce que vous pouvez m’éclairer ?
Autre chose, le lien vers la webui me renvoie une erreur nginx 502… Pourtant j’avais pu y accéder ç un moment…
Salut,
disons que là je comprends mieux ce que tu m’expliques.
En tous les cas j’ai relancer le noeud et il a l’air de fonctionner. Duniter est bien pris en compte par systemd, ce qui enlève les logs 'avertissements de yunohost dans les services. Oui, je pense que c’est bien de l’ajouter.
J’ai des soucis avec la webui que j’avais aussi auparavant, là je ne sais pas bien pourquoi, mais je crois que c’est peut-être trop lourd simplement pour mon serveur… si je l’atteint et que je me balade qur des onglets, il y a forcément un moment où ça plante…
Bonjour @roodinux j’ai le même constat chez moi.
Le service duniter.service n’a pas les autorisations nécessaires pour démarrer en auto lors d’un reboot du serveur.
erreur:
systemd[317]: duniter.service: Failed to determine user credentials: No such process
systemd[317]: duniter.service: Failed at step USER spawning /usr/bin/duniter: No such process
systemd[1]: duniter.service: Control process exited, code=exited, status=217/USER
systemd[1]: duniter.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Duniter node.
également constater qu’il faut ajouter sudoers à l’utilisateur « duniter » pour permettre l’installation du package yunohost/duniter correctement.
Pour ce faire il faut lancer en étant root la commande visudo et ajouter l’utilisateur duniter
User privilege specification
root ALL=(ALL:ALL) ALL
duniter ALL=(ALL:ALL) ALL
Ensuite la commande: sudo systemctl enable duniter.service devrait permettre le démarrage auto
A tester
la résolution de fork à la main, c’est assez expérimental (ou mal documenté). Si tu trouves, ce serait chouette de poster la solution. Et oui, il faut être patient, et attendre de voir si ton noeud se resynchronise après chaque série de commandes, ce qui peut prendre plusieurs dizaines de minutes.