Perte de membres calculant sur la Ğ1


#1

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 :

@ofontes @matiou @Moul @Inso @floppy @Pafzedog @jytou @PiNguyen @Mententon03 @mamygeek @matograine @ji_emme @gerard94 @stephane @oaktree @Florentin @Jean_Ferreira @Pol @Paulart


#2

@cgeek peut-être pourrait t’on augmenter forkWindowSize pour que les nœuds décrochent moins facilement ? Que dirai tu de passer de 100 a 200 blocks ?

Ça ferai toujours moins d’une journée comme rollback max :slight_smile:


#3

Pour info, je dois sans cesse resynchroniser Duniter depuis la version 1.7.11. C’est normal ?


#4

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.


#5

Pour info également : je dois relancer Duniter plusieurs fois par jour et resynchroniser tous les 2 ou 3 jours.


#6

Mon nœud tombe également régulièrement. Je le relance…


#7

En théorie non :sweat_smile:
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 :laughing:


#8

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.


#9

J’ai réinstallé la version 1.6.30 de Duniter,sur les conseils de @gerard94 car je voulais installer WotWizard.

Je dois me resyncroniser c’est ça?

2019-03-09T20:29:09+01:00 info WS2P: init: bundle of peers 20/67
2019-03-09T20:29:24+01:00 info WS2P: Could not connect to peer 5oGdiLzs using `WS2P 91.178.157.40 20900: WS2P connection timeout`

2019-03-09T20:29:24+01:00 info WS2P: Could not connect to peer Hb2TLnB6 using `WS2P 83.134.45.233 20900: WS2P connection timeout`

2019-03-09T20:29:24+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:24+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:24+01:00 info WS2P: Could not connect to peer 2N6fqEkA using `WS2P g1.olibre.fr 443: WS2P connection timeout`

2019-03-09T20:29:24+01:00 info WS2P: Could not connect to peer F3ciajMy using `WS2P g1.duniter.uras.ovh 443: WS2P connection timeout`

2019-03-09T20:29:24+01:00 info WS2P: Could not connect to peer 9ghhup5M using `WS2P 126.65.173.13 20900: WS2P connection timeout`

2019-03-09T20:29:24+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:24+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:24+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:24+01:00 info WS2P: init: bundle of peers 21/67

2019-03-09T20:29:24+01:00 trace WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:BPEap6B98qBxTmUMoxvCtuP2JXFMjX7kDJT1RaYn3UbS:5faf97fa-bd60-48d3-988c-23baf10f7441a257b08c-d156-41d2-b972-cc9cd3817997

2019-03-09T20:29:24+01:00 trace WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:BPEap6B98qBxTmUMoxvCtuP2JXFMjX7kDJT1RaYn3UbS:593db2ba-3b99-4240-8405-4a8247d45a2b2ab0978b-3cb9-4111-aca3-3268e89c34b6

2019-03-09T20:29:24+01:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE

2019-03-09T20:29:24+01:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE

2019-03-09T20:29:39+01:00 info WS2P: Could not connect to peer 6rHJDzyh using `WS2P 88.127.220.178 20900: WS2P connection timeout`

2019-03-09T20:29:39+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:39+01:00 info WS2P: Could not connect to peer HWZ69923 using `WS2P 78.224.171.210 20900: WS2P connection timeout`

2019-03-09T20:29:39+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:39+01:00 info WS2P: Could not connect to peer GYU7DWbc using `WS2P 78.251.5.57 20900: WS2P connection timeout`

2019-03-09T20:29:39+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:39+01:00 info WS2P: Could not connect to peer EC88p19i using `WS2P 78.251.5.57 20900: WS2P connection timeout`

2019-03-09T20:29:39+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:39+01:00 info WS2P: init: bundle of peers 22/67

2019-03-09T20:29:54+01:00 info WS2P: Could not connect to peer BULmjVtP using `WS2P 107.159.21.38 20900: WS2P connection timeout`

2019-03-09T20:29:54+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:54+01:00 info WS2P: Could not connect to peer 4tNQ7d9p using `WS2P g1-monit.librelois.fr 443: WS2P connection timeout`

2019-03-09T20:29:54+01:00 info WS2P: Could not connect to peer 537LMVBq using `WS2P 88.126.20.5 20901: WS2P connection timeout`

2019-03-09T20:29:54+01:00 info WS2P: Could not connect to peer 7U9L243W using `WS2P 78.210.20.127 20900: WS2P connection timeout`

2019-03-09T20:29:54+01:00 info WS2P: Could not connect to peer AgYKG4FZ using `WS2P 81.64.114.181 20900: WS2P connection timeout`

2019-03-09T20:29:54+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:54+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:54+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:54+01:00 debug WS2P: init: failed connection

2019-03-09T20:29:54+01:00 info WS2P: init: bundle of peers 23/67

2019-03-09T20:29:54+01:00 trace WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:BPEap6B98qBxTmUMoxvCtuP2JXFMjX7kDJT1RaYn3UbS:2c79f09f-0a71-402c-9075-0dff30918b7418d5842e-ec6d-448d-8ba1-f426bd4c5905

2019-03-09T20:29:54+01:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE

2019-03-09T20:29:54+01:00 trace WS2P >>> sendCONNECT >>> WS2P:CONNECT:g1:BPEap6B98qBxTmUMoxvCtuP2JXFMjX7kDJT1RaYn3UbS:1d92955c-2215-4a1e-82f4-c825c9c4bd7d713f769c-23b3-4ee6-b093-9fa85aa7a432

2019-03-09T20:29:54+01:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE

2019-03-09T20:29:59+01:00 warn Unknown reference block of peer

2019-03-09T20:30:00+01:00 warn Unknown reference block of peer

2019-03-09T20:30:00+01:00 warn Unknown reference block of peer

2019-03-09T20:30:00+01:00 warn Unknown reference block of peer

2019-03-09T20:30:00+01:00 warn Unknown reference block of peer

 

#10

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 -_-


#11

@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 :frowning: )


#12

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.


#13

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 ?


#14

C’est gtest.jytou.fr :slight_smile:


#15

Bonjour,
Perso j’ai plus de réseau depuis hier soir. D’habitude c’est signalé sur le site de free mais là, rien. Ptêt problème dû au vent.


#16

J’ai voulu resynchroniser mon nœud sur ts.gt.librelois.fr
mais ça c’est arrêté ici :

Progress:

Milestones:   [||||||||||||||||||||] 100 %
Download:     [||||||||||||||||||  ] 93 %
Apply:        [||||||||||||||||||  ] 90 %
Sandbox:      [                    ] 0 %
Peers:        [                    ] 0 %

Status: Peers.../usr/bin/duniter: line 15:  1568 Killed                  $NODE "$DUNITER_DIR/bin/duniter" "$@"

#17

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.


#18

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.


#19

Processus tué par le système car trop de mémoire ou CPU utilisé ?


#20

@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.