@Moul c’est un problème de corruption de ton fichier wot, si tu reset data et sync ce sera résolu.
Je ne vois que 2 explications possibles :
Ton noeud s’est arrêté de manière inopiné, ce qui a corrompu le fichier wot. J’ai déjà remarqué ce comportement, hélas pas évitable, il faudrait plutôt faire en sorte que Duniter s’arrête moins souvent.
C’est un noeud 1.7 que tu a mis à jour en 1.8 sans reset data, et il ne s’est jamais arrêté tout seul, dans ce cas c’est le code de migration qui flanche.
@matograine attention il ne faut jamais faire cela, ce sont 2 paquets différents et indépendants donc considérés comme logiciels différents par ton OS alors qu’il utilisent les mêmes ressources. Il faut impérativement désinstaller la variante server avant d’installer la variante desktop, et vice versa.
Chez moi ça tourne bien, mais avec direct_start le CTRL+C le ferme salement :
2020-05-28T00:23:19+02:00 - error: Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed
at ChildProcess.target.send (internal/child_process.js:636:16)
at Worker.send (internal/cluster/worker.js:40:28)
at PowWorker.sendCancel (/opt/duniter/app/modules/prover/lib/PowWorker.js:81:27)
at slaves.forEach (/opt/duniter/app/modules/prover/lib/powCluster.js:121:22)
at Array.forEach ()
at Master.cancelWorkersWork (/opt/duniter/app/modules/prover/lib/powCluster.js:120:21)
at Master.cancelWork (/opt/duniter/app/modules/prover/lib/powCluster.js:130:14)
at PowEngine.cancel (/opt/duniter/app/modules/prover/lib/engine.js:43:29)
at WorkerFarm.stopPoW (/opt/duniter/app/modules/prover/lib/blockProver.js:70:53)
at BlockProver.cancel (/opt/duniter/app/modules/prover/lib/blockProver.js:122:24)
Ça je ne le corrigerai pas, surtout que cette partie est déjà migré, juste pas embarquée en 1.8 car il y a d’autres soucis, qui devraient être résolus par une migration plus avancée (couche d’accès a la base de donnée notamment).
J’ai redémarré mon noeud Desktop après avoir supprimé le dossier et resynchronisé.
Or, j’observe dans les logs qu’il a tenté de calculer des blocs avec la clef publique automatiquement générée (non-membre) :
2020-05-28T20:05:05+02:00 - info: Matched 4 zeros 00009DAC4211BB938573C4FCE8DF86E424FF35BDF971B7D29FC915480325E945 with Nonce = 10100000006789 for block#325866 by E9P3nw
2020-05-28T20:05:10+02:00 - info: Matched 4 zeros 0000E724A8ABBE6EB7CFF6D7EE085AA41C6DE74298B86C9D77FADDF36C73AE2F with Nonce = 10100000012238 for block#325866 by E9P3nw
2020-05-28T20:05:18+02:00 - info: Matched 4 zeros 00007D5D568A9FA296C3546F94536B4F6D4744ECF1907F58FD27331CFE03DE96 with Nonce = 10200000022738 for block#325866 by E9P3nw
Ceci ne se reproduit pas lorsque je change de nouveau le keyring pour un compte non membre.
Il y a quelque chose que je ne vois pas : quand on a testé une fonctionnalité, on édite directement le post en mode wiki ou on le signale quelque part avant ?
Pour ma part, après avoir lancé duniter-desktop pour linux générique, la synchronisation commence mais s’arrête avec l’erreur
2020-06-01T12:14:06+02:00 - error: Could not get a validation from remote blockchain after 15 trials. Stopping sync.
Lancer le programme une deuxième fois ne mène pas à cette erreur. Dois-je cocher la case
Le programme duniter-desktop est utilisable sur GNU/Linux avec le paquet .tar.gz x64
Ma priorité étant la migration en Rust, je ne m’engage à corriger que les bugs bloquant pendant la migration.
Pour moi un bug bloquant c’est : un bug qui empêche le fonctionnement d’une fonctionnalité indispensable ET pour lequel il n’existe aucune solution de contournement.
Il se peut que je corrige également des bugs non-bloquants si j’en ai l’envie (c’est d’ailleurs ce que j’ai fait pour la commande wizard network, qui n’est pas une fonctionnalité indispensable), mais je ne m’engage pas sur ces derniers.
Ce n’est pas bloquant, et cela concerne en plus un module déjà oxydé (prover), juste pas encore intégré dans une release, je ne prévois pas de le corriger.
On édite directement le post en mode wiki
Et si tu penses qu’il y a des informations complémentaires à communiquer à propos de ce test, et bien tu écris un post dans ce fil.
Ce n’est pas un bug bloquant, c’est un problème réseau, cela signifie que l’un des noeuds du réseau n’est pas joignable derrière le endpoint indiqué sur sa fiche de peer.
Il faudrait refondre complètement le code de la sync réseau pour mieux gérer ça, je ne le ferai pas, je prévois d’écrire directement WS2Pv2 en Rust dans Duniter (en reprenant ton code d’ailleurs) quand la migration sera suffisamment avancée pour le permettre.
oui
Perso je ne gère pas l’interface web, tu peux créer un ticket sur le dépôt de duniter-ui qui est maintenu par @cgeek mais rien ne dit que ce sera corrigé, en tous les cas ça ne bloquera pas la sortie de Duniter 1.8.
On aurait grand besoin d’un dev front motivé pour reprendre l’interface graphique de Duniter, j’en ai parlé à @ManUtopiK qui m’a dit qu’il regarderait
Je ne sais pas si c’est bloquant ou non, car il me manque le contexte, dans quel contexte s’est produit cette erreur ?
Merci pour toutes ces réponses. L’erreur affichée n’est pas bloquante, c’est juste bizarre de voir du rouge dans le terminal. Pour information, duniter fonctionne parfaitement dans WSL (windows subsystem linux) version serveur comme version desktop. Je vais probablement faire un tutoriel un de ces jours pour documenter le fonctionnement.
Ce bug n’est peut-être pas nouveau, mais mon nœud s’est bloqué au bloc 325608 (il a le même que le réseau), a forgé le 325609, et quand il essaie de résoudre le fork il trouve que le 325609 du réseau est invalide :
$ duniter pull g1.e-is.pro:443
2020-06-01T16:41:30+02:00 - debug: Plugging file system...
2020-06-01T16:41:30+02:00 - debug: Loading conf...
2020-06-01T16:41:30+02:00 - debug: Configuration saved.
2020-06-01T16:41:30+02:00 - debug: Opening SQLite database "/home/tuxmain/.config/duniter/duniter_default/duniter.db"...
2020-06-01T16:41:31+02:00 - debug: Now open indexers...
2020-06-01T16:41:32+02:00 - debug: Opening SQLite database "/home/tuxmain/.config/duniter/duniter_default/txs.db"...
2020-06-01T16:41:32+02:00 - debug: Opening SQLite database "/home/tuxmain/.config/duniter/duniter_default/peers.db"...
2020-06-01T16:41:34+02:00 - debug: Upgrade database...
2020-06-01T16:41:34+02:00 - info: Block resolution: 0 potential blocks after current#325609...
2020-06-01T16:41:34+02:00 - info: Fork resolution: 97 potential block(s) found...
2020-06-01T16:41:35+02:00 - info: Fork resolution: 1 potential suite(s) found...
2020-06-01T16:41:35+02:00 - info: Fork resolution: HEAD = block#325609
2020-06-01T16:41:35+02:00 - info: Fork resolution: suite 1/1 (-> #325708-000000) revert to fork point block#325608
2020-06-01T16:41:35+02:00 - debug: Reverting block #325609...
2020-06-01T16:41:48+02:00 - info: Fork resolution: suite 1/1 REFUSED block#325609: ruleToBeKickedArePresent
2020-06-01T16:41:59+02:00 - info: Block #325609 added to the blockchain in 3103 ms
2020-06-01T16:41:59+02:00 - info: Looking at g1.e-is.pro:443...
2020-06-01T16:42:00+02:00 - error: Block already known
2020-06-01T16:42:00+02:00 - debug: Trying to close SQLite...
2020-06-01T16:42:00+02:00 - debug: Trying to close SQLite...
2020-06-01T16:42:00+02:00 - info: Database closed.
2020-06-01T16:42:00+02:00 - info: Database closed.
2020-06-01T16:42:00+02:00 - debug: Trying to close SQLite...
2020-06-01T16:42:00+02:00 - info: Database closed.
Ça c’est une corruption du fichier wotb, @Moul a eu exactement le même problème, je pense que c’est le code de migration qui ne fonctionne pas bien, du coup la 1.8 vas nécessiter une resynchronisation lors de la mise à jours, je vais l’indiquer.
J’ai (enfin !) ouvert des places en WS2P public (je n’ai toujours pas bien compris ce que c’est ), avec les ports kivonbien sur le routeur + parefeu.
Mais…
J’avais 10 places « private » et 10 « public ». Je suis passé à 4 « private » et 25 « public » (sur mon noeud diurne) comme conseillé sur cette discussion. Mais en réalité, je suis à 6 connexions « outcoming » (donc private, si j’ai bien compris) en non 4, mon max. J’ai bien relancé le noeud.
Est-ce effectivement un bug ? Je préfère demander avant d’ouvrir une issue.
WS2P est l’API de communication entre les nœuds Duniter. Bien que le “langage” de cette API soit symétrique, il faut toujours un nœud pour initier la connexion et un nœud pour la recevoir.
Le nœud qui reçoit la connexion doit nécessairement avoir un endpoint WS2P public connu et correctement configuré. S’il n’en a pas, il ne pourra pas recevoir de connexion, il devra se contenter d’en initier auprès des autres nœuds qui peuvent en recevoir.
Tu vois donc que le réseau Duniter dépend entièrement des nœuds WS2P Public, leur rôle est crucial, s’ils viennent à manquer le réseau ne peut pas fonctionner et la monnaie s’arrête.
Non le quota de connexions sortantes n’est pas un mur infranchissable mais une limite à partir de laquelle Duniter n’essaye plus d’initier de nouvelles connexions, il est donc dépassable temporairement.
Pour que tu comprenne vraiment pourquoi il faudrait que je t’explique le code qui applique les quotas, c’est un peu compliqué.
J’ai remarqué que parfois je suis en public parfois en privé. Ça se fait tout seul sans que je touche à rien. Est-ce parce que je n’ai pas touché à la conf d’origine ? Ou le public prend-il ‹ la main › quand il n’y a plus assez de noeuds ?