Avec la version 1.6.15 je n’avais pas de problème. C’est en passant à la version 1.6.16 que le problème apparait.
C’est curieux oui, moi non plus (version serveur) je ne calcule plus de blocs, ou plutôt je n’en trouve pas car j’ai bien des logs de calcul. Tout se passe comme si le cluster de preuve n’était pas notifié des changements opérés dans la blockchain, et donc soit il reste “dans sa preuve” très longtemps, soit il reste “à ne rien faire”.
Malheureusement je ne sais pas si je pourrais jeter un œil ce soir 
1 Like
De mon coté je trouve bien des blocs et avec chacun de mes 3 nœuds membres, tous ont la dernière release duniter-server 1.6.16 (paquet debian amd64). En revanche, depuis le passage a la 1.6.15 j’ai une activité cpu bizarre et c’est bien lié a duniter :
Alors que je suis réglé à 60%, duniter consomme 100% du cpu lorsque je sort de la fenêtre d’exclusion et il faut un temps aléatoire pour qu’il redescendre a 60%, c’est peut être lié a un problème de communication avec le cluster de preuve effectivement :
Il semble aussi que duniter continue a calculer même lorsque je suis exclu 
Oui je confirme, même chose ici. Du coup, je vais probablement rebasculer sur la 14 quand j’ai un moment.
Edit : c’est un truc à rajouter au cahier de tests… 
- ah ben non, doublé par cgeek… 
C’est d’autant plus étrange que ça fait bien 1 ou 2 semaines que je faisais tourner la version avec justement les derniers correctifs sur la preuve de travail (car on a mis longtemps à valider son bon fonctionnement), sans soucis. Ou alors je ne l’ai pas remarqué.
Je pense que tu ne l’a tout simplement pas remarquer, comme je fais du monitoring permanent je vois plus de choses. En fait la fois ou j’ai cru reproduire le bug #1234 sur ta nouvelle version du cluster pow c’est exactement le comportement présent que j’avais remarquer, qui est effectivement différent du bug #1234.
Comme j’étais le seul a avoir ce comportement et que j’étais bien incapable de vous dire comment le reproduire, j’ai cru que ça venais de mon environnement, il semblerait que non.
Tu as pu retélécharger la 14 ? Je ne la trouve nulle part. (elle a été supprimée de github)
EDIT : D’ailleurs tous les tags ont disparu https://git.duniter.org/nodes/typescript/duniter/tags
Effectivement, c’est curieux!
Il se trouve que je l’avais encore (faut que je fasse le ménage dans les download… ah ben en fait non! 
)
En attendant mieux, je l’ai posée là.
Oui, retrouvé. Par contre les tags ont été tous anti-datés sur le github. Comment ça se fait ?
Qu’entend tu par “anti-datés” ?!? Je vois toujours marqué jytou released this on 14 Nov 2017
Ok ce n’est pas de l’anti-datage, c’est les 28 tag de test qui ont été nécessairent a faire fonctionner le *** de script python de création de la tag page gitlab. Il est vrai que j’aurais pu désactiver la synchro github pendant ces tests, je n’y ai pas pensé.
Est-ce qu’on peut les supprimer du coup ?
Je viens de tester oui on peu mais seulement 1 par 1, c’est long 
EDIT : Je crains qu’a la 1ère sync github il repush tout les tag, si c’est le cas la réponse est en fait non
EDIT2: je viens de tester et je confirme, a chaque commit tout les tag sont repusher et gitlab ne me propose pas d’option pour supprimer les tag → conclusion : non on ne peut pas les supprimer.
Si tu vas sur la page des tags de Gitlab, il y a un bouton (icône poubelle) en face de chaque tag pour le supprimer…
En tout cas je vois 10 membres en 1.6.16 sur la g1, et parmsi eux 7 sont dans la fenetre courante et certains sont même très bien placés : @elois LionelTouseau @Moul @kimamila @Pafzedog @vincentux et @fbuland.
Donc il est faux de dire que la 1.6.16 ne calcule pas de blocs. Elle en calcule bien !
En revanche, il semble qu’il y ai un problème avec le cluster de pow qui de fait rend le calcul plus compliqué, d’où les chutes anormales de la diff commune les 19, 22 et 24 janvier.
EDIT : Ce qui est difficile c’est que ce problème ne se produit pas de manière systématique, sur mes 3 nœuds membres g1 par exemple, un seul semble touché.
Je suis bien admin général du gitlab mais pour autant je ne peut pas supprimer les tag, je ne pense pas que ce soit un problème de droits, ça doit être refuser par gitlab parce qu’il y a des releases associés