J’ai rencontré un bug similaire alors que mon nœud diurne rattrapait le retard qu’il a pris la nuit, il n’avait pas atteint le HEAD du réseau. J’ai redémarré le nœud et il a rejoint le HEAD du réseau.
Je pense que mes multiples redémarrages des nœuds g1-test.cgeek.fr et g1-test.duniter.org associés au bug de PoW annulée y sont pour quelque chose quand on a aussi peu de nœuds WS2P.
Mais continuez d’observer ! Je fais de même. Je vais essayer d’ajouter un ou deux nœuds ce week-end.
2 Likes
Alors c’est très bizarre, la web-ui m’indique désormais qu’il bien au bloc 56582 mais si je clique sur NETWORK puis que je reviens sur OVERVIEW il m’affiche de nouveau 56070 puis au bout de 15s il passe a 56582.
Sachant qu’il ne calcule aucun bloc alors qu’il en calculait hier, je pense qu’il est en train de reswither en ping-pong éternel d’une branche a l’autre ou alors il y a un bug dans l’affichage, mais je suis sûr qu’il ne calcule pas je monitore l’activité cpu.
EDIT : d’après les log je crois que c’est bien un problème de résolution de fork :
017-09-21T16:14:21+02:00 - e[32minfoe[39m: Block resolution: 0 potential blocks after current#56070...
2017-09-21T16:14:21+02:00 - e[32minfoe[39m: Fork resolution: 72 potential block(s) found...
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: httpCode=400, ucode=1015, message=Document already under treatment
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:21+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:22+02:00 - e[33mwarne[39m: Block already known
2017-09-21T16:14:23+02:00 - e[32minfoe[39m: ⬇ PEER 4XXUjyto
2017-09-21T16:14:23+02:00 - e[32minfoe[39m: ✘ PEER 4XXUjyto
2017-09-21T16:14:23+02:00 - e[33mwarne[39m: Unknown reference block of peerJ’essaie de faire fonctionner un noeud purement WS2P sans nginx devant. J’ai donc désactivé BMA et configuré ws2p avec les commandes :
./bin/duniter config --ws2p-noupnp --ws2p-port 7778 --ws2p-host 37.187.192.109 --ws2p-remote-port 7778 --ws2p-remote-host 37.187.192.109
./bin/duniter config --nobma
Le parefeu est ouvert, mais il m’est impossible de joindre mon noeud. Même en local :
nc 37.187.192.109 7778
(UNKNOWN) [37.187.192.109] 7778 (?) : Connection refused
C’est comme si duniter n’avait pas réussi à ouvrir le port ws2p. Pourtant dans les logs je ne vois pas d’erreur particulière :
2017-09-21T19:52:18+02:00 - info: >> Server starting...
2017-09-21T19:52:18+02:00 - info: Node version: 1.6.4
2017-09-21T19:52:18+02:00 - info: Node pubkey: 5GXtSTTXpvnhLq4TiQM1uaFuiSZaXyEZGYETX95j6WMU
2017-09-21T19:52:18+02:00 - warn: Local node is not a member. Waiting to be a member before computing a block.
2017-09-21T19:52:18+02:00 - info: Sibling endpoints:
2017-09-21T19:52:18+02:00 - info: ⬇ PEER 5GXtSTTX
2017-09-21T19:52:18+02:00 - info: ✘ PEER 5GXtSTTX
2017-09-21T19:52:18+02:00 - error: httpCode=400, ucode=2023, message=Peer document already known
2017-09-21T19:52:18+02:00 - info: Next peering signal in 31 min
2017-09-21T19:52:28+02:00 - info: WS2P: Could not connect to peer -------- using `WS2P 37.187.192.109 7778: WS2P connection timeout`
2017-09-21T19:52:28+02:00 - warn: WS2P >> Streamer >> WS2P connection timeout
2017-09-21T19:52:28+02:00 - info: Block resolution: 0 potential blocks for root block...
2017-09-21T19:52:28+02:00 - info: >> Server ready!
Le show conf ne me dit rien :
$ ./bin/duniter ws2p show conf
$
Bef je suis un peu largué là…
Tu devrais voir un message “WS2P […] listen” quelque part si ton nœud est correctement configuré. Il te manque l’option --ws2p-public je pense.
Pour voir la config, la commande est duniter ws2p show-conf.
Cool ! Ca a l’air mieux mais :
2017-09-22T08:07:24+02:00 - info: Sibling endpoints:
2017-09-22T08:07:24+02:00 - info: WS2P 5GXtSTTXpvnhLq4TiQM1uaFuiSZaXyEZGYETX95j6WMU: new incoming connection from 37.187.192.109:37544!
2017-09-22T08:07:24+02:00 - info: ⬇ PEER 5GXtSTTX
2017-09-22T08:07:24+02:00 - info: ✘ PEER 5GXtSTTX
2017-09-22T08:07:24+02:00 - error: httpCode=400, ucode=2023, message=Peer document already known
2017-09-22T08:07:24+02:00 - info: Next peering signal in 31 min
2017-09-22T08:07:24+02:00 - error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE
2017-09-22T08:07:34+02:00 - info: WS
C’est normal cette erreur ?
Soit la clé publique qui répond n’est pas celle attendue à l’adresse indiquée, soit le nœud qui répond n’est pas sur la même monnaie que le nœud qui tente la connexion. Ou les deux à la fois, ce qui est tout à fait possible si la connexion pointe vers un nœud d’une autre monnaie.
Je crois que ton nœud est connecté au mien, mais le tiens semble désynchronisé.
Si tu as accès à l’interface graphique, pourrais-tu aller dans “Settings > Backup > Create a data backup” et m’envoyer le fichier via https://framadrop.org ? Tu peux m’envoyer le lien par MP sur le forum.
Par avance merci !
edit : il semble que ce ne soit plus vrai depuis quelques minutes, je ne sais pas si tu as fait quelque chose ou non.
Dans ce cas ce serait bien de faire un backup de duniter.db et wotb.bin, et de les partager pour qu’on puisse tous regarder.
Et concernant les nombreux messages :
WS2P >> Streamer >> WS2P connection timeout
Je reproduis. Il semble que la connexion websocket soit perdue à un moment donné mais incorrectement traitée dans Duniter, ce qui fait que la connexion n’est jamais réétablie.
J’ai créé le ticket #1116 à cet effet.
Je viens de tester, et j’ai quelques questions.
- J’ai l’impression que je reste bloqué sur le premier bloc après le “sync”. J’essaye d’arrêter et de relancer pour voir. (Effectivement, après redémarrage cela a l’air d’aller mieux.)
- Même après duniter stop, j’ai 4 processus node qui tournent en prenant plein de cpu. Je peux les tuer ? Quand je relance duniter, j’ai 8 nodes qui tournent, et j’ai toujours 8 nodes après l’avoir quitté.
- Mon nœud continue à calculer une PoW pour un bloc qui a déjà été trouvé (je vois bien les messages comme quoi on annule le calcul sur le cluster, mais je continue à voir des messages « matched 3 zeros … » pour le vieux bloc).
- Est-ce que cette erreur est grave: « error: Peer with zero endpoints that is not already known » ?
- Est-ce que mon nœud sera visible sur la page https://g1.duniter.fr/#/app/network ? Ce sera sous quel nom ?
Ça semble être un bug. On a déjà rencontré ce bug. Quelle est l’architecture processeur de ton Odroid. Si c’est sur ARM64, tu dois être le premier à tester sur cette architecture.
Je pense pas que ça soit grave. C’est à titre informatif.
Normalement oui dans le cas de BMA.
Pour WS2P, c’est sur /network/ws2p/{info,heads}
C’est un armv7l, donc 32 bits.
Qu’est-ce que je peux faire pour aider à débugger ?
@cgeek, je pensais avoir la journée pour tester un peu en détails mais ça ne s’est pas passé comme ça.
Je n’arrive plus à voir l’interface graphique, même en lançant duniter avec l’argument webstart. J’ai peut-être fait une bêtise dans la configuration du réseau…
Peux-tu me préciser où sont les fichiers à sauvegarder?
Ok, c’est si c’est de l’armv7l, c’est une architecture armhf et non 32bits.
Oui, mais cgeek pourra mieux te guider pour débugger ça.
Je confirme que c’est une armhf. Je ne savais pas que c’était différent de 32 bits.
En effet, je viens de reproduire avec la 1.6.4. J’ai ouvert le ticket #1117.
C’est étrange comme comportement, es-tu bien sur la version 1.6 de Duniter ? La plateforme armhf y est peut-être aussi pour quelque chose vu qu’il n’existe pas de binaire NodeJS disponible pour celle-ci. J’ai besoin d’investiguer, mais je ne possède pas cette plateforme pour tester moi-même 
Oui. Je vais changer le niveau de log pour ce message à debug.
Si j’ai bien compris tu ne vas pas activer BMA, donc non ton nœud n’y sera pas visible pour l’instant. Sauf si @kimamila décide d’ajouter les nœuds découverts sous /network/ws2p/heads.
Tu ne peux pas faire de bêtise concernant l’UI, elle est toujours disponible sur http://localhost:9220. Mais pour cela il te faut utiliser la commande duniter webstart ou duniter direct_webstart.
À noter qu’un bug a été découvert à ce sujet pour ceux qui installent Duniter manuellement, en le compilant. https://forum.duniter.org/t/livrables-arm-en-attente-raspberry-pi-3-hs/3249/31
Dans le répertoire ~/.config/duniter/duniter_default/, fichiers wotb.bin et duniter.db.
Merci, j’ai repéré le bug et après correction les blocs manquants sont bien téléchargés et la résolution s’effectue correctement. Tu peux suivre l’évolution du correctif dans le ticket #1118.
J’utilisais la 1.6.4 fournie sur le github. J’essaye de compiler une version manuellement, mais pour le moment les tests ne passent pas. Dès que cela marchera, je testerai avec.
Je croyais qu’activer BMA était déconseillé. Je peux le faire, en ouvrant des ports sur ma box.
Oui je le déconseille étant donné les retours faits par des utilisateurs ARM. Car BMA est vraiment très peu optimisé et gourmand en ressources. De plus il est voué à être abandonné sur le moyen/long terme.
Le fait d’avoir uniquement WS2P privé devrait suffire à faire fonctionner ton nœud et lui permettre le calcul de blocs.
Si ton nœud fonctionne bien avec WS2P (privé et/ou public), il devrait être visible ici sous 5 minutes :
Pour le moment il ne fonctionne pas bien. La version binaire ne sait pas abandonner le calcul d’une PoW (même quand elle apprend que le bloc a été calculé, elle continue à le chercher), et la version compilée à la main ne passe pas les tests (manque de RAM, cf Livrables ARM en attente : Raspberry PI 3 HS - #32 by Alan_Schmitt)