Désynchro rapide de mon serveur Ğ1

Mon serveur g1-test se porte bien, merci pour lui. :wink:

Mais celui de la Ğ1, juste après la synchro, se bloque à essayer de forger un bloc obsolete :

Matched 4 zeros 000073DB9B0E01037D7C101C24FEA92DCDBB684DCB34101B01FBC1C1029558E6 with Nonce = 10000005992343 for block#377256 by 7F6oyF

Ma vue réseau :

API Pubkey WS2PID Member Step HEAD Software Prefix Free Rooms
WS2POCAIC 8UXZWg5YZ3FJvPYvKQTM 7fce0727 troubadour 1 377261-00000004E3E145C7A8 duniter 1.8.0 1 31:23
WS2POCAIC 5fPevx21yusT83Xujgs7 3074f33e 1 377261-00000004E3E145C7A8 duniter 1.7.21 1 20:20
WS2POCAIC J8q7ufHdAHGdAqNgHnzB 871d6889 1 377261-00000004E3E145C7A8 duniter 1.8.0 42 20:20
WS2POCAIC FEkbc4BfJukSWnCU6Hed 4e810faa jytou 1 377260-0000001E49135CAE74 duniter 1.7.21 3 10:10
WS2POCAIC A2C6cVJnkkT2n4ivMPiL df25f4da bricodeur 2 377260-0000001E49135CAE74 duniter 1.8.0 1 0:0
WS2POCAIC Do99s6wQR2JLfhirPdpA 5fbb76af poka 2 377260-0000001E49135CAE74 duniter 1.8.0 1 10:10
WS2POCAIC 82NdD9eEbXSjRJXeJdqf 39030fda Mententon 2 377260-0000001E49135CAE74 duniter 1.8.1 1 20:20
WS2POCA 7QRZwBYWVCNn99vUPEex 0909116c 1 377259-0000000123080D2B89 duniter 1.8.0 1 0:0
WS2POCAIC DmUyu2bppLJBYmNwCd2q 90df62a4 Muisec 2 377259-0000000123080D2B89 duniter 1.8.0 1 0:0
WS2POCA 4qKUdXviHNxxUc9pPSHX 1955d51e 1 377257-0000000ACEE88240F3 duniter 1.8.1 1 0:0
WS2POCAIC GX1nYVburxeaVP1SCNuh 882a5ad1 1 377257-0000000ACEE88240F3 duniter 1.8.1 1 0:0
WS2POCAIC 7F6oyFQywURCACWZZGtG 5e2dfbd5 vit 0 377255-00000000596034522B duniter 1.8.1 1 8:8

Pourquoi suis-je aussitôt figé comme ça après une synchro ?

Ah un indice !

Fork resolution: block #377256-0000000C is known as incorrect. Skipping.

1 Like

Problème déjà connu, mais je ne pourrais pas le régler avant très longtemps, car ça concerne une codebase js que je ne maîtrise pas et que je suis très loin de migrer.

C’est l’algo de résolution de fork qui à plusieurs comportements bizarres et pas d’équerre du tout… Ici il a rejeté le bloc #377256-0000000C par le passé pour de bonnes raisons (par ex. bloc pas chainable).

Entre-temps le bloc serait chainable maintenant, mais il est dans les invalidFork, comme la cause de l’invalidité n’est pas tracée le code ne peut pas savoir si le bloc doit être réévalué ou non. Ce que je veux dire c’est que ça ne peut pas se corriger comme ça, c’est tout l’algo qu’il faudrait refaire, un gros chantier la aussi (oui il y a hélas beaucoup de gros chantiers).

Pour contourner le problème: comme les forks invalide sont uniquement en RAM, il suffit de restart duniter.

3 Likes

J’ai restart deux fois, une fois par ansible, toujours bloqué, et restart avec l’interface, toujours bloqué… :sleepy:

Qu’est ce qui te fait dire que tu es toujours bloqué ? A tu toujours le log block #377256-0000000C is known as incorrect ?

Si oui essaye de revert des blocs : duniter revert 20

Et si ça ne donne toujours rien alors je n’ai pas de solution autre que resync. Oui c’est bloquant, mais je ne peut rien n’y faire, cette partie du code est une boite noire trop illisible pour moi et trop délicate, si j’essaye de la modifier ça peut empirer et causer l’arrêt de la Ğ1.

La seule chose que je puisse faire, c’est remplacer entièrement toute la brique par un algo de résolution des forks en Rust, car je sais ce que le métier est censé faire au global sur cette partie et que j’ai déjà un proto-algo dans Dunitrust plutôt prometteur (mais qui ne gère pas encore correctement tous les cas).
Ce serait un trop gros chantier pour la 1.9 qui a déjà beaucoup trop de changements, donc ça attendra dsl, en attendant il faut avoir de la chance quand on sync.

Une astuce pour resync plus vite lorsque la dernière sync est très récente : sauter la partie «download» en réutilisant les chunk json précédement téléchargés :

cp .config/duniter/duniter_default/g1 .config/duniter/duniter_default/g1.sav
duniter reset data
duniter sync /home/USER/.config/duniter/duniter_default/g1.sav

Bien entendu cumulable avec l’astuce /dev/shm :wink:

3 Likes

Non aucun rapport…

1 Like

OK désolé, merci.

Oui:

2020-11-29T11:02:33+00:00 info Fork resolution: 102 potential block(s) found...
2020-11-29T11:02:33+00:00 info Fork resolution: block #377256-0000000C is known as incorrect. Skipping.
2020-11-29T11:02:33+00:00 info Fork resolution: block #377256-0000000C is known as incorrect. Skipping

J’ai tenté le revert 20, avec duniter lancé, puis avec duniter stoppé :

2020-11-29T11:44:45+00:00 - debug: Plugging file system...
2020-11-29T11:44:45+00:00 - debug: Loading conf...
2020-11-29T11:44:45+00:00 - debug: Configuration saved.
2020-11-29T11:44:45+00:00 - debug: Opening SQLite database "/var/lib/duniter/duniter_default/duniter.db"...
2020-11-29T11:44:45+00:00 - error: OpenError: IO error: lock /var/lib/duniter/duniter_default/data/leveldb/level_blockchain/LOCK: Resource temporarily unavailable
    at /duniter/duniter/node_modules/levelup/lib/levelup.js:119:23
    at /duniter/duniter/node_modules/abstract-leveldown/abstract-leveldown.js:38:14
    at /duniter/duniter/node_modules/deferred-leveldown/deferred-leveldown.js:31:21
    at /duniter/duniter/node_modules/abstract-leveldown/abstract-leveldown.js:38:14

J’ai supprimé le fichier LOCK puis relancé revert 20, le fichier LOCK est recréé et la même erreur se produit.

Oui, tout cela me fait dire que je suis bloqué et même locké… :sweat_smile:

[edit]
Avec Docker, faire un

docker exec container_duniter duniter stop

vous fera croire que vous avez stoppé le process, mais que nenni… D’où mes problèmes de DB verrouillée !
Maintenant, je stop vraiment le service docker, je fais revert 20 et ça fonctionne (ça revert).

A suivre…

1 Like

Pourriez-vous me fournir un fichier de config pour la Ǧ1 qui fonctionne ? Je l’adapterai à mon réseau.

Ce qui m’arrive:

  • Après une synchro G1, mon serveur déclare le bloc à venir comme corrompu et essai de forger le sien.
    Il reçoit et conserve les blocs des autres serveurs qui continue à avancer en side. Mais il insiste pour forger le bloc numéro « fin de sync + 1 », à l’infini…

Comme je supprime tout sauf les fichier conf.json et keyring.yml, avant chaque synchro, je soupçonne la configuration de causer le problème. (C’est une vieille config qui a toujours fonctionné, et fonctionne encore avec G1-test).

{
 "currency": "g1",
 "endpoints": [],
 "rmEndpoints": [],
 "upInterval": 3600000,
 "c": 0.0488,
 "dt": 86400,
 "dtReeval": 15778800,
 "ud0": 1000,
 "stepMax": 5,
 "sigPeriod": 432000,
 "sigReplay": 5259600,
 "sigValidity": 63115200,
 "msValidity": 31557600,
 "sigQty": 5,
 "xpercent": 0.8,
 "percentRot": 0.67,
 "powDelay": 0,
 "avgGenTime": 300,
 "dtDiffEval": 12,
 "medianTimeBlocks": 24,
 "httplogs": false,
 "udid2": false,
 "timeout": 3000,
 "isolate": false,
 "forksize": 100,
 "switchOnHeadAdvance": 3,
 "nonWoTPeersLimit": 100,
 "txsMempoolSize": 200,
 "msPeriod": 5259600,
 "storage": {
  "transactions": true,
  "wotwizard": false
 },
 "loglevel": "info",
 "cpu": 0.05,
 "nbCores": 1,
 "prefix": 1,
 "nobma": false,
 "bmaWithCrawler": false,
 "upnp": false,
 "dos": {
  "whitelist": [
   "127.0.0.1"
  ],
  "maxcount": 50,
  "burst": 20,
  "limit": 40,
  "maxexpiry": 10,
  "checkinterval": 1,
  "trustProxy": true,
  "includeUserAgent": true,
  "errormessage": "Error",
  "testmode": false,
  "silent": false,
  "silentStart": true,
  "responseStatus": 429
 },
 "ws2p": {
  "uuid": "882a5ad1",
  "privateAccess": true,
  "publicAccess": true,
  "preferedOnly": false,
  "privilegedOnly": false,
  "upnp": false,
  "host": "127.0.0.1",
  "remotehost": "g1.elo.tf",
  "port": 20901,
  "remoteport": 443,
  "remotepath": "ws2p",
  "maxPublic": 7,
  "maxPrivate": 3
 },
 "proxiesConf": {
  "reachingClearEp": "clear",
  "forceTor": false
 },
 "sigStock": 100,
 "sigWindow": 5259600,
 "idtyWindow": 5259600,
 "msWindow": 5259600,
 "rootoffset": 0,
 "remoteport": "443",
 "ipv4": "127.0.0.1",
 "port": "10901",
 "remotehost": "g1.elo.tf",
 "udTime0": 1488970800,
 "udReevalTime0": 1490094000
}

Je suis enfin dans la course ! :partying_face:

Le problème venait donc bien de mon fichier de configuration qui n’était pas bon (paramètres de la monnaie/wot).

Cela me pose question sur le cycle de vie du fichier de configuration.
Quand on lance Duniter pour la première fois, s’il n’existe pas, il crée un fichier de configuration.
Mais les paramètres ne corresponde pas à la Ğ1 (ni à Ğ1-test je crois).

A quel moment peut-on mettre à jour les paramètres de la monnaie/wot de ce fichier (qui visiblement sert à une vérification des blocs, car maintenant que j’utilise tes paramètres ça fonctionne, il ne considère plus le dernier bloc comme invalide) avec ceux de la monnaie choisie ?

Visiblement pas lors d’une synchro.

Le fichier de conf est créé lors de la 1ère commande lancée. Si cette 1ère commande est une sync alors c’est bien la sync qui va fixer les paramètres en fonction du bloc genesis reçu.

Mais si la toute première commande est autre chose qu’une sync, alors un fichier de conf par défaut est créé.

En tout état de cause, le fichier de conf ne devrait pas être utilisé dans la validation globale, quand je migrerai cette partie je changerai ça.

3 Likes