Yes ! Pas mal de galères, mais enfin j’y suis.
Par contre Césium m’affiche un Endpoint plutôt bizarre : 0.0.0.0:20900
Statistiquement, avec le fonctionnement de mes scripts il devrait bel et bien y avoir des transactions chaînées, mais je n’ai pas vérifié plus que ça… peut-être qu’elles étaient tout simplement refusées quand elles arrivaient ou simplement repoussées au prochain bloc ? Il me semblait pourtant me rappeler même qu’elles causaient problème justement. Mais ça doit être un effet Mandela.
En fait elles posaient problème lors d’une synchronisation. Donc au fil de l’eau il ne devait pas y avoir de problème, en tout cas pas de connu.
Oui j’ai vu ça aussi, tu peux modifier le fichier ~/.config/duniter/duniter_default/conf.json
pour changer cela manuellement si tu veux, dans la section “ws2p”. Il faut plutôt y mettre une IP publique.
J’ai recréé un compte pour remettre un noeud maintenant que la 1.7 a bien avancé
inso2018
CaE9dyy4GLsZ1QoVziDXUDbxFyxM82PPPmTjYdjf2K7h
Certifié !
certifié aussi
et de 4…
et de 5…
Parfait !
Bon mon noeud va mettre un peu de temps a être up parce qu’il faut que je migré sur un nouveau vps, l’autre étant bloqué sur un kernel 2.6… Demain soir normalement
Je suis toujours en grosse difficulté pour mettre à jour mon noeud :
Progress:
Milestones: [|||| ] 20 %
Download: [||| ] 18 %
Apply: [||| ] 18 %
Sandbox: [ ] 0 %
Peers: [ ] 0 %
Status: GOT chunck #197/1114 from 49250 to 49499 on peer g1-test.duniter.orgg1test@vps614673:~/duniter$
Le systeme de monitoring me kill le process parce qu’il prend trop de CPU. La configuration de --cpu 0.2
ne semble pas avoir d’effet, au mois lors de la phase de sync. Aurais-tu une solution ?
Ton nœud tourne dans le vide je pense, car il n’arrive pas à télécharger.
En cas de grosse difficulté comme actuellement sur ĞTest (trop peu de nœuds dispos), lancer la sychro avec l’option --slow
qui va permettre d’attendre bien plus longtemps l’obtention des blocs auprès des pairs.
Pardon, je n’ai pas mis l’accent sur le problème : le noeud plante en fait.
Regarde tout à droite, le cli rend la main :
n peer g1-test.duniter.orgg1test@vps614673:~/duniter$
OK, mais essaie l’option --slow quand même. Ça le détend un peu
Si c’est toujours trop violent, je vais voir pour que l’option --cpu soit prise en compte durant la synchro. Tu es le 2ème à spontanément penser à cette option, avec @vit.
Je viens de voir que mon noeud était totalement à l’ouest bien que toujours actif (je ne monitor que le fait que le service soit up ) je vais essayer de vous rattraper et passer en 1.7.1 du même coup
Je n’arrive pas à démarrer mon noeud (après transpilation + synchronisation complète) :
[4516503.797071] traps: gtest[24978] trap invalid opcode ip:7f0399b2e213 sp:7f03978d2d50 error:0 in leveldown.node[7f0399abb000+282000]
C’est quoi la distribution + le système ?
Déso de pas vous avoir rejoints, j’en suis à la 3e resync en 3 jours
Je reste en 1.6, voir si ça foire qq part.
Alpine Linux 3.8 sur x86_64
NodeJS 8.11
Essayes plutôt avec NodeJS 9.
Et aussi, quelle commande lances-tu ? Est-ce Duniter UI ? Est-ce la commande sync
en direct ?
Et voilà, mon noeud a été migré ! Accessible sur g1test.duniter.inso.ovh
EDIT : Erf, en fait petit bug détecté :
g1test@vps614673:~/duniter$ ./bin/duniter direct_start
2018-11-20T23:00:20+01:00 - debug: Plugging file system...
2018-11-20T23:00:20+01:00 - debug: Loading conf...
2018-11-20T23:00:20+01:00 - debug: Configuration saved.
2018-11-20T23:00:20+01:00 - debug: Opening SQLite database "/opt/g1test/.config/duniter/duniter_default/duniter.db"...
2018-11-20T23:00:20+01:00 - debug: Opening SQLite database "/opt/g1test/.config/duniter/duniter_default/txs.db"...
2018-11-20T23:00:20+01:00 - debug: Opening SQLite database "/opt/g1test/.config/duniter/duniter_default/peers.db"...
2018-11-20T23:00:21+01:00 - debug: Upgrade database...
2018-11-20T23:00:21+01:00 - info: Block resolution: 0 potential blocks after current#279342...
2018-11-20T23:00:21+01:00 - info: >> Server starting...
2018-11-20T23:00:21+01:00 - info: NodeJS version: v9.4.0
2018-11-20T23:00:21+01:00 - info: Node version: 1.7.1
2018-11-20T23:00:21+01:00 - info: Node pubkey: CaE9dyy4GLsZ1QoVziDXUDbxFyxM82PPPmTjYdjf2K7h
2018-11-20T23:00:21+01:00 - info: BMA server listening on http://127.0.0.1:8999
2018-11-20T23:00:21+01:00 - error: Error on WS Server
2018-11-20T23:00:21+01:00 - error: Error: listen EACCES ::1:80
at Object._errnoException (util.js:1003:13)
at _exceptionWithHostPort (util.js:1024:20)
at Server.setupListenHandle [as _listen2] (net.js:1349:19)
at listenInCluster (net.js:1407:12)
at doListen (net.js:1522:7)
at process._tickCallback (internal/process/next_tick.js:152:19)
2018-11-20T23:00:21+01:00 - error: Error: listen EACCES ::1:80
at Object._errnoException (util.js:1003:13)
at _exceptionWithHostPort (util.js:1024:20)
at Server.setupListenHandle [as _listen2] (net.js:1349:19)
at listenInCluster (net.js:1407:12)
at doListen (net.js:1522:7)
at process._tickCallback (internal/process/next_tick.js:152:19)
Pour la configuration réseau suivante :
"remoteport": "80",
"ipv4": "127.0.0.1",
"ipv6": "::1",
"port": "8999",
"remotehost": "g1test.duniter.inso.ovh"
Le port 80 est celui de nginx, duniter devrait essayer d’écouter sur le port 8999… ?