Nous ne sommes plus que 14 à calculer les blocs pour une monnaie à 1700 membres, c’est peu, d’autant que nous étions environ 35 en moyenne les mois précédents.
Il est très probable que cela soit lié à des nœuds perdus dans des forks, je me permets de vous notifier ici pour vous prévenir que votre nœud ne calcule plus :
Pour ma part, mon nœud n’arrivait pas à rejoindre la branche majoritaire car un bloc de cette branche ne respectait pas une règle du protocole.
Je n’ai malheureusement plus le log d’erreur. Si des personnes ont encore leur nœud bloqué, peut-être peuvent-ils le partager ici avant de resynchroniser.
En théorie non
cgeek investigue, ce qui pourrait l’aider c’est que la prochaine fois que notre noeud se désynchronise, fournir les log avant de resync, je le dit aussi pour moi car je le fait pas
Depuis la version 1.7.11 de Duniter aucune de mes sessions MintLinux sur mes i7 MacBookPro ne parvient plus à accrocher le moindre “Connected peers”, au contraire des mac anciens de tous les Windows, et qu’importe le nombre de réinstallations, réinitialisations etc …
Il va falloir me dire comment faire et sinon je vais devoir redescendre d’une version.
Prochaines grandes vacances je réessaye d’installer sur un Raspberry…
…mais avec aucune connaissance autre que les traitements de texte les 2 premières tentatives se sont soldées par des beaux échecs -_-
@cgeek
J’ajoute mon noeud à la liste : des désynchronisations très fréquentes, et parfois il s’arrête… En tout cas ça fait bien longtemps qu’il n’a plus tenu une journée d’affilée.
(Pour info je suis sur Raspberry)
Promis j’essaierai de choper les logs la prochaine fois (mais c’est pas hyper pratique sur termux )
J’étais prêt à écrire le message suivant mais en fouillant un peu je me suis aperçu que le fait d’avoir plusieurs nœuds dans mon réseau local en n’utilisant que les noms DNS pour les différencier pose des problèmes au niveau de la fiche de pair qui se mélange les pinceaux. Du coup mes diagnostics sur les dernières semaines sont probablement faux. Je laisse quand même le message d’origine au cas où et pour ne pas perdre mes observations.
Du coup je repars avec une différenciation principalement basée sur le port (mais je garde aussi le nom DNS tant qu’à faire) et je rajoute une machine un peu plus costaud qu’une carte de crédit histoire de mettre un peu de support sur la blockchain. Et sinon sur gtest je suis le seul membre calculant depuis plusieurs jours, il faudrait peut-être resynchro vos nœuds sur le mien (qui est joignable en BMAS, il va pas vite mais il tourne).
Pareil pour moi : j’ai un raspi qui ne tient en général pas une journée synchro. Il part tout seul dans un coin et bloque pour ne plus jamais rejoindre les wagons. Par contre, j’ai remarqué qu’en faisant un restart du nœud lorsqu’il n’est pas trop loin (mois de 100) de la chaîne principale, il se resynchro souvent dessus alors qu’il n’y arrivait pas autrement. Dans les logs, on voit qu’il rajoute bien les blocs de la chaîne principale dans une « side chain » mais en les marquant invalides. Par contre, je pense que ce qui donne le plus de peine aux petits nœuds type raspi, ce n’est pas la longueur de la blockchain mais plutôt le nombre de nœuds, en particulier les nœuds désynchronisés : tout ce « bruit » prend une place trop importante dans flux de données et j’ai l’impression que c’est ça qui le fait bloquer. Du coup j’ai aussi installé un second nœud sur un banana pi (disque SATA, 2Go de mémoire, il est plus puissant qu’un raspi, c’est g1b.jytou.fr) en me disant que ça passerait peut-être mieux mais en fait non, il fait grosso modo la même chose que le raspi. Voilà, ça fait 3 semaines que j’expérimente en regardant au moins une fois par jour où ils en sont et en tentant de les garder le plus synchro possibles, mais même en y passant du temps, ils ne restent pas synchros. Pour la petite histoire sur le raspi le nœud plante assez souvent par manque de mémoire, j’ai fait un petit script qui le redémarre quand il a planté.
Sinon j’ai mis en place récemment une redirection avec apache : tout ce qui entre dans mon IP arrive sur le serveur qui redirige ensuite sur mon réseau local en fonction de l’adresse DNS appelée. Du coup quiconque tente d’attaquer le nœud par mon adresse IP directement n’arrive jamais au nœud, il faut impérativement passer par le nom. Je ne sais pas si ça joue dans les désynchros (avant j’utilisais un même nom et une adresse IP et la redirection se faisait par des ports différents genre 9004, maintenant tout est sur 80/443 et redirigé par nom DNS). Mes nœuds sont configurés pour donner leur adresse DNS et pas leur IP.
Mon nœud gtest s’était bloqué dans un fork.
Je l’ai synchro sur g1-test.duniter.org où uniquement bbv à écrit les dernièrs blocs.
Au final, mon nœud écrit l’histoire tout seul. Quelle est l’adresse de ton nœud pour m’y synchroniser ?
Pourquoi pas, mais à mon avis ce n’est pas tant la longueur des forks qui joue qu’un bug dans la résolution. J’aimerais explorer d’autres pistes avant.
Oui, j’ai remarqué cela hier en tentant de comprendre pourquoi Remuniter aussi avait forké. Je l’ai relancé il a raccroché des blocs immédiatement avant d’être à nouveau bloqué car trop loin dans le retard.
Je partage ton analyse, les Raspi (ou petites config) ne tiennent pas longtemps la synchro. Pour moi c’est effectivement lié à trop de « bruit » du réseau, la charge CPU/HDD est trop importante pour eux.
Cela dit, il y a selon moi une énorme marge d’optimisation de Duniter à ce niveau.
@MarcelDoppagne@Pol@sveyret@DYves62@Paulart@Darunya@piaaf31 je vais essayer de suivre vos nœuds, je développe actuellement un outil de monitoring réseau de la Ğ1. Ce n’est pas encore terminé, mais quand ce sera le cas j’aurai de quoi diagnostiquer plus finement ce qui s’est produit et aussi je pourrais obtenir des alertes dès qu’une anomalie se produit (perte de synchro, perte de connectivité, etc).
En attendant, je ne peux que vous conseiller de resynchroniser.
)