the 1.6.15 and 1.6.16 versions never starts the calculation of blocks
For two days (since the installation of 1.6.15 and 1.6.16 just a little later), my Duniter linux desktop produces no more blocks and looks like the following picture. Where may I be wrong?
Related merge requests 2
When these merge requests are accepted, this issue will be closed automatically.
Activity
@ge Please make sure in your log that your node is calculating:
you have to find that line sometimes:
2018-01-21T17:17:29+01:00 - info: Matched 3 zeros 0007FADAA261F5A3C1B43544199B278CDFCA480B305A08E44432ECCFAA2B4442 with Nonce = 10200000319187 for block#88244 by D9D2zaEdited by Éloïsadded W-awaiting user checks label
added W-probably a false positive label
added M-prover T-bug T-releases and removed W-awaiting user checks W-probably a false positive labels
@librelois Unfortunately, I don't have enough knowledge of the product to know where this could come from. If you have an idea of where I could look at…
removed T-releases label
-
@sveyret alors bonne nouvelle pour toi le problème n'est pas spécifique a la version desktop, le changement du mécanisme de build des releases ne semble pas en cause ;)
@c-geek Je pense que le problème viens du coté asynchrome, peut-être que parfois le cluster de pow est lancée sur un nouveau bloc sans avoir vraiment annulé ses travaux sur le bloc précédent, je pense que le async dans cette ligne est en cause : https://git.duniter.org/nodes/typescript/duniter/blob/1.6/app/modules/prover/lib/engine.ts#L36
Qu'en pense tu ?
Edited by Éloïs mentioned in merge request !1238 (merged)
mentioned in commit 700d6df3
mentioned in commit 9871890e
mentioned in issue #1262 (closed)
@librelois Oui clairement le problème vient de la communication avec le cluster. Le Graal pour outrepasser le problème est d'implémenter #1262 (closed), mais demande la migration vers Node 9 (n'est pas une LTS) ou Node 10 (LTS, qui débute en avril 2018). J'aimerais réaliser cela pour la 1.7.0, qui apportera donc enfin une solution définitive et sûre à 100%, car la communication sera assurée.
Mais je pense que temporairement, une solution moins élégante mais plus rapide serait d'ajouter un garde-fou type fichier, scruté périodiquement par les workers et qui leur indiquerait s'ils sont bien en phase avec le programme principal ou non, et donc de s'arrêter en cas d'erreur.
Qu'en penses-tu ?
-
Mais je pense que temporairement, une solution moins élégante mais plus rapide serait d'ajouter un garde-fou type fichier, scruté périodiquement par les workers et qui leur indiquerait s'ils sont bien en phase avec le programme principal ou non
Je pense qu'on ne peut effectivement pas faire mieux avec Node 8... donc faisons ça !
Edited by Éloïs Si vous livrez une nouvelle pré-release, il y aura peut-être un intérêt a intégrer !1240 (merged) …
+1 @sveyret, excellent boulot de présentation et de coding, tout cela me semble très propre !
mentioned in commit 6c076243
mentioned in commit 4acfe365
I've just pushed some code. I'm currently testing the solution, but I think it's OK. My pseudo is coming back in the top list of issuers in Remuniter since this fix: http://remuniter.cgeek.fr
mentioned in commit 8e879c3e
mentioned in commit f71f7df7
mentioned in commit 7b597352
mentioned in commit 0b3f4e3f
closed via commit 4fd9397f
closed via merge request !1238 (merged)
mentioned in commit 4fd9397f
