Bloquage de la Ğ1 du 02/01/2020 dû du fait de la non exclusion d’une identité

g1.nordstrom.duniter.org est-il dispo maintenant ?

Il est semble-t-il coincé sur un vieux bloc, bien avant le fork…

Ça rattrape doucement le retard, mais c’est en bonne voie :

|   block |       gentime       |     mediantime      |    hash    |       uid        |
|---------+---------------------+---------------------+------------+------------------|
|  285511 | 2020-01-03 17:53:46 | 2020-01-03 15:30:58 | 000002C116 |     charles      |
|  285510 | 2020-01-03 17:42:20 | 2020-01-03 15:19:32 | 00000B7E90 |       poka       |
|  285509 | 2020-01-03 17:30:55 | 2020-01-03 15:08:07 | 00000A860C |     ji_emme      |
|  285508 | 2020-01-03 17:19:29 | 2020-01-03 14:56:41 | 0000011A95 |       deem       |
|  285507 | 2020-01-03 17:08:04 | 2020-01-03 14:45:16 | 00000B014C |     Guenoel      |

Pas d’erreur dans les logs duniter. Il faut que les forgeurs continuent de rejoindre la branche non bloquée.

Retard quasiment rattrapé :

Current block: n°285577, generated on the 2020-01-04 06:27:42
Generation of next block n°285578 possible by at least 14/20 members
Common Proof-of-Work difficulty level: 70, hash starting with `0000[0-9]*`
|       uid        |        match         |   Π diffi   |   Σ diffi |
|------------------+----------------------+-------------+-----------|
|  MarcelDoppagne  | 00000000000000000000 | 8.6 × 10^68 |       914 |
|     gerard94     | 00000000000000000000 | 8.1 × 10^31 |       420 |
|     ji_emme      | 00000000000000000[0- | 3.5 × 10^21 |       284 |
|       moul       | 0000000000000[0-9]*  | 2.7 × 10^16 |       214 |
|       deem       |      000000000*      | 6.9 × 10^10 |       144 |
|      jytou       |    00000000[0-1]*    | 6.0 × 10^10 |       142 |
|     charles      |      0000[0-6]*      | 5.9 × 10^5  |        73 |
|     pafzedog     |      0000[0-7]*      | 5.2 × 10^5  |        72 |
|     art15te      |      0000[0-7]*      | 5.2 × 10^5  |        72 |
| jeanlucdonnadieu |      0000[0-8]*      | 4.6 × 10^5  |        71 |
|     Attilax      |      0000[0-8]*      | 4.6 × 10^5  |        71 |
|    Matograine    |      0000[0-8]*      | 4.6 × 10^5  |        71 |
|    b_presles     |      0000[0-8]*      | 4.6 × 10^5  |        71 |
|      elois       |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|     ofontes      |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|      bherfa      |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|     Scott76      |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|       poka       |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|     Granxis8     |      0000[0-9]*      | 3.9 × 10^5  |        70 |
|     Guenoel      |      0000[0-9]*      | 3.9 × 10^5  |        70 |

avec une difficulté qui a chuté à 70.

Bonjour à tous
Je compte lancer dans la soirée un nœud duniter sur mon Raspberry Pi4. Me faut-il éviter de me synchroniser sur g1.duniter.org ?

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 ! :smile:

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… :expressionless:

1 Like

Pour ceux qui sont sur raspi, je vous conseille mes scripts pour éviter de vous énerver de trop. :stuck_out_tongue: 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