par contre, peu de pair connectés, 5 maxi jusque là (avec la version windows, j’en avais 10) et l’heure ne se met pas à jour… mais visiblement, ça calcule.
1 Like
Je suppose que tu as uploadé le paquet Debian ARM Stretch en rajoutant -stretch à la syntaxe du nom de l’archive duniter-server-v1.8.0-linux-armv7l-stretch.deb.
Ça n’est pas nécessaire, car l’upload a un hash qui permet de les identifier, bien qu’une fois téléchargés, les paquets ont le même nom et ne sont plus identifiables.
Il se trouve que ça pose un problème pour que le paquet YunoHost récupère le paquet Debian, étant donné que la syntaxe du lien a changé.
Je préfère re-uploader sans ce changement de nom. Sinon il faut gérer deux cas conditionnels non nécessaires ici.
J’ai réuploadé sans le -stretch dans le nom du paquet. Peux-tu faire attention à ce point la prochaine fois ?
Pour l’instant, ça calcule mais je n’ai calculé aucune transaction (je ne sais pas si c’est le bon langage…).
Le 2048 blocks produits par cette clé (image précédente) n’apparait plus et sur « reseau », j’obtiens « 0 » au step.
Est-ce normal?
Merci
« step » c’est le nombre de pas entre ton nœud et le nœud. « 1 » signifie que ton nœud est directement connecté à celui-ci, « 2 » qu’il est connecté à un nœud qui y est connecté… et « 0 » que c’est le tien. 
1 Like
stretch étant la oldstable nous ne sommes pas obligés de la supportée; et ça me semble bien que ce paquet est un nom différent, deux paquets avec le même nom c’est confusant pour l’utilisateur.
Je comprends que ça fait plus de choses à gérer derrière pour ceux qui construisent des choses à partir de ce paquet mais ce n’est pas mon problème. Ma priorité c’est la simplicité et la lisibilité des pour les, utilisateurs de Duniter qui utilisent les livrables officiels.
Le titre du lien précise pour quelle version de Debian s’agit-il, est-ce que ça répond suffisamment à ta problématique ?
Donc, tu ne veux pas le faire à l’avenir ? Sinon, je le ferais tant que YunoHost v4.0 ne sera pas sortie, qui vient avec le support de Buster.
Merci Tuxmain.
Autre question, tt à l’heure, sur cesium reseau, j’étais en « accès privé » et là, j’ai carrément mon adresse IP qui s’affiche. Comment se fait-ce?
Non, je ne veux pas que 2 paquets différents aient le même nom. Tu peux proposer un autre nom qui te semble plus pertinent, mais je veux qu’ils aient un nom différent 
1 Like
Bonsoir, encore moi… De temps en temps, mon noeud, qui m’indique qu’il bosse reste bloqué sur un block. Je suis obligée de relancer duniter pour qu’il reparte. Mon ordi ne passe pas en veille normalement… Peut-être faut-il que je le synchronise sur un autre noeud…
Je me réponds à moi même mais à suivre, ça pourra peut-être servir à qq’un. Pour résoudre mon pb de blocage, j’ai fait un « crontab » duniter webrestart toutes les 6 heures. Comme le webrestart suffisait, pas besoin de resynchroniser, on verra ce que ça donne comme ça.
1 Like
Duniter ne supporte pas la reprise de veille. Je ne comprends pas pourquoi, mais je sais que ça le bloque, il n’arrive pas à se synchroniser.
1 Like
Pourtant mon ordi ne passe pas en veille… Un « crontab duniter webrestart » toutes les 2h. Cela minimise les temps de bloquage. Ça a l’air de fonctionner…
1 Like
J’ai également des problèmes lors de la synchronisation sur un Raspberry Pi 2 B avec 1Go de mémoire (pas de swap). Ça serait sans doute une bonne idée de fournir une blockchain comme cela directement téléchargeable et mise à jour régulièrement pour les petits systèmes qui ont du mal à s’initialiser…
EDIT: et on pourrait indiquer l’astuce dans le Wiki de Duniter… 
2 Likes
Je crois savoir qu’il y a des fuites de RAM sur la version pour raspi qui finissent par planter le Pi et faire décrocher duniter. J’ai trouvé une solution maline (mais pas pérenne) grâce aux scripts de jytou (scripts for duniter) qui surveillent le processus et relancent duniter avec une synchro quand c’est nécessaire… Depuis, je n’ai plus à y toucher sauf coupure d’électricité. Je bénis jytou.
On peut aussi rajouter de la swap (avec un disque dur ssd par exemple) pour booster la ram, c’est pas interdit.
D’autre part, j’avais lu qu’il fallait mininmum un Pi3 pour faire tourner duniter, donc je ne suis pas surpris qu’un pi2 décroche rapidement : pas assez de ressources…
1 Like
La synchronisation nécessite à minima 2 Go de mémoire vive.
Non, car cette technique permet juste de contourner les aléas réseau. C’est la phase d’indexation de la blockchain qui nécessite 2 Go de mémoire vive, pas la récupération des blocs sur le réseau.
En tous les cas donc, Duniter ne peut pas fonctionner sur une machine avec moins de 2Go de mémoire vive.
2 Likes
Zut… Bon, pour le moment, j’ai ajouté une clé USB de 1Go en swap. Si ça ne suffit pas, je me ferai une swap de 10Go en NFS.
Ensuite, en fonctionnement normal, est-ce qu’1Go de mémoire suffit ?
Je ne pense pas. Certes, en mode start Duniter consomme beaucoup moins (autour de 300 Mo), mais des pic de conso mémoire peuvent survenir lors de résolution de fork par exemple. Je préconise 2 Go de RAM minimum tout le temps.
1 Like
Aïe… Bon, et bien je laisserai ma clé à demeure…
Hum, ça commence à être beaucoup. Il est temps que l’on arrive à diminuer la conso mémoire si le but de Duniter reste de pouvoir fonctionner sur des machines modestes.
3 Likes
Juste au cas où, est-ce que la base de données peut être transmise d’une machine à l’autre, ou est-ce que cela dépend de l’architecture, de l’endianness, de la largeur du bus ? Si jamais ma synchronisation plante sur un ARM 32 bits, est-ce que je peux la tenter sur un amd64 et ensuite transférer le répertoire duniter_default sur l’ARM ?