G1-test dans les choux ? État monnaie

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 :thinking:

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. :stuck_out_tongue:

1 Like

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.

1 Like

J’ai recréé un compte pour remettre un noeud maintenant que la 1.7 a bien avancé :slight_smile:

inso2018
CaE9dyy4GLsZ1QoVziDXUDbxFyxM82PPPmTjYdjf2K7h

Certifié !

1 Like

certifié aussi :wink:

1 Like

et de 4… :heavy_check_mark:

1 Like

et de 5… :heavy_check_mark:

1 Like

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 :slight_smile:

1 Like

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 :slight_smile:

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.

1 Like

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 :sweat_smile:) je vais essayer de vous rattraper et passer en 1.7.1 du même coup :wink:

1 Like

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]

:scream:

C’est quoi la distribution + le système ?

Déso de pas vous avoir rejoints, j’en suis à la 3e resync en 3 jours :smiley:

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 :slight_smile:

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… ?