Je précise que g1.duniter.org est le nœud sur lequel je me suis synchronisé il y a plus d’un mois en tant que miroir, pour vérifier que ça fonctionnait. J’ai ensuite arrêté le système. Là, je vais tout remettre en route avec une connexion rapide et créer un nœud membre, et donc lancer une nouvelle synchro… Y a-t-il un reset de la précédente synchro à faire au préalable ?
Moi j’ai jamais fait de reset et ça a toujours marché… jusqu’à présent.
Mon nœud est actuellement fonctionnel et synchronisé, il a forgé un bloc il y a quelques minutes. Ça te dirait d’essayer de faire la synchro à partir de mon nœud, pour voir si ça marche ?
La commande serait alors : duniter sync 79.85.173.136:10901 --nointeractive
–nointeractive est en option, pour voir tout ce qu’il fait pendant la synchro, ça peut être intéressant, même on comprend pas tout le charabia qui défile…
J’ai lancé mon nouveau nœud duniter membre (sur raspi 4) au moment du Fork apparemment.
J’ai donc lancé une resynchro sur g1.presles.fr mais ça n’avançait pas du tout (genre 15000 blocs en 24h et ensuite complètement bloqué à 22000).
J’ai donc relancé une synchro sur, au hasard parmi la bonne branche, g1.le-sou.org. C’est plus rapide, en 12h, ça en est au bloc 30718, mais quand même, ça ne me semble pas très rapide (30718 alors que le bloc courant est le 285888). Je me dis que si dans quelques années, quelqu’un doit relancer une synchro et que ça synchronise à cette vitesse, ça va prendre longtemps.
Est-ce que ça pourrait être un bug sur mon nœud fraîchement installé (raspi 4, debian 10, duniter 1.7.19 arm Server) du coup? et pas lié au fork…
Non, c’est pas normal. Avec raspi4 sur le même fork (g1.presles.fr) j’ai synchronisé avant-hier en deux heures et calculé 4 blocs en 24h… 24h c’était avec les vieilles versions de duniter et raspi3, ça fait longtemps que ça m’est pas arrivé.
2020-01-05T19:11:35+01:00 - error: Error: ESOCKETTIMEDOUT
at ClientRequest.<anonymous> (/opt/duniter/node_modules/request/request.js:819:19)
at Object.onceWrapper (events.js:255:19)
at ClientRequest.emit (events.js:160:13)
at TLSSocket.emitTimeout (_http_client.js:708:34)
at Object.onceWrapper (events.js:255:19)
at TLSSocket.emit (events.js:160:13)
at TLSSocket.Socket._onTimeout (net.js:412:8)
at ontimeout (timers.js:458:11)
at tryOnTimeout (timers.js:296:5)
at Timer.listOnTimeout (timers.js:259:5)
du coup j’ai essayer avec mon ordi de faire une synchro. J’ai essayé au moins 10 fois et rien à faire. Au mieux, j’ai téléchargé 94% et c’est resté bloqué.
Merci jytou, je vais regarder tes scripts et je vais continuer à essayer avec mon ordi.
Je viens de lancer ./resync.sh ; ./watchit.sh et ça semble bien parti. Merci jytou.
Moi je faisais duniter sync g1.presles.fr 443 mais ça fonctionne mieux sans préciser le port on dirait dis donc.
Ensuite, j’ai une question @jytou : pour que watchit.sh fonctionne, il faut garder la liaison ssh du raspi ouverte tout le temps?
Update après 10 min, mon ordi est à 99% (je croise les doigts) et le raspi est à 61% (Incroyable!!!).
Update après 15 min, mon ordi est 100% de download et 98% d’Apply (Yes!)
J’ai resynchronisé mon noeud également, il semble par contre qu’il n’y ait pas eu de DU depuis le 2 janvier. Vous constatez aussi ça ou c’est mon cesium qui bugge (déjà observé).