Oui vaut mieux. Moi je me suis connecté sur g1.presles.fr et ça marche, pour l’instant…
1 Like
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 ?
j’ai fait un duniter reset all pour que tout soit propre, perso…
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…
Ça marche ! 
J’ai commencé un post pour documenter l’investigation d’un fork : Comment investiguer un fork?
Si vous avez des choses à rajouter, n’hésitez pas!
1 Like
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é.
1 Like
J’ai essayé plusieurs fois hier de synchroniser sur différents nœuds sur la bonne branche, ça a planté à chaque fois. C’est un peu énervant… 
1 Like
Pour ceux qui sont sur raspi, je vous conseille mes scripts pour éviter de vous énerver de trop. 
https://git.duniter.org/jytou/scripts-for-duniter
4 Likes
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)
Toujours pas moyen qu’une synchro passe…
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.
1 Like
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!)
La syntaxe de la commande sync a changé :
sync server [block_number]
Donc ne plus mettre le port en argument !
La doc n’est pas à jour… je cherche où je peux trouver la doc sur les commandes duniter…
3 Likes
[block_number] ? Peux tu me donner un exemple.
Présentement je synchronise avec duniter sync g1.presles.fr.
Il faudrait mettre à jour le wiki de duniter.org pour éviter des écueils à d’autres car ici, https://duniter.org/fr/wiki/duniter/configurer/#synchroniser-votre-nœud , ça dit toujours duniter sync DUNITER_NODE_HOST DUNITER_NODE_PORT
La commande est celle-ci, le block number désigne le bloc de fin je crois.
duniter sync DUNITER_NODE_HOST [BLOCK_NUMBER]
Si tu laisse 443, alors la synchro stoppe au bloc 443 (de mémoire).
3 Likes
ça expliquerait tout.
En passant, mon raspi 4 est du coup synchro à 97% en 45min. C’est pas la même en effet. Je croise les doigts.
Edit : synchro effectuée sur raspi 4 en 1h exactement!
2 Likes
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é).
++
Le plus simple est d’utiliser la commande screen qui permet de faire tourner un shell en arrière plan.
Par exemple :
screen -S duniter
Tu te retrouves alors dans une session screen et tu lances les commandes que tu veux, comme ./resync.sh ; ./watchit.sh
Quand tu as fini de lancer les commandes que tu voulais et que ton process tourne, tu fais [Ctrl]-A-D pour te détacher de screen. La session screen continue à tourner dans son coin, et toi tu te retrouves dans ton shell d’origine.
Tu peux alors regarder quelles sont les sessions screen qui tournent en faisant screen -ls.
Et là, tu peux te délogger, ça continue à tourner dans la session screen qui est maintenant détachée de ton shell. Quand tu reviens quelques heures/jours/mois plus tard, tu peux te rebrancher sur la session screen en faisant :
screen -r duniter
Et si tu veux que la session screen s’arrête pour de bon, il suffit de faire [Ctrl]-d comme pour faire un exit d’une session shell. C’est quand même bien foutu ! 
5 Likes
merci, merci beaucoup. C’est trop cool!