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 ?
Pour une synchro rapide il est nécessaire d’utiliser beaucoup de RAM. Peut-être qu’il sera possible de proposer une option “synchro frugale” qui consommera très peu de RAM mais qui sera alors 10 à 100 fois plus lente.
La bdd est portable, tu peut la transférée d’une machine a l’autre, y compris sous architecture différente.
En revanche, je l’ai moi même déjà fait et j’ai parfois eu des problèmes, car leveldb n’a pas de système de recovery, donc si la copie n’est pas parfaite ça ne fonctionnera pas. Ce point sera très nettement amélioré quand on aura migré sous sled.
4 Likes
Bon, j’ai finalement réussi et démarré le nœud. Il semble fonctionner. Par contre, j’ai essayé de me mettre derrière un reverse proxy et je ne suis pas sûr d’avoir bien réussi. J’ai plein de messages comme :
error: Unhandled rejection: WS2P connection timeout
error: WS2P connection timeout
warn: WS2P: cannot connect to incoming WebSocket connection: WS2P connection timeout
error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INCORRECT_ASK_SIGNATURE_FROM_REMOTE
info: Matched 4 zeros 0000C299D65F4AF86C2595B4737968CF9670E9362BEC8F751E69939B3DD48EA5 with Nonce = 10100000020908 for block#340109 by 9UuWHs
error: WS2P >>> >>> WS ERROR: ANSWER_TO_UNDEFINED_REQUEST
Est-ce que je dois m’inquiéter ?
Je ne vois pas pourquoi on ne pourrait pas juste faire une synchro rapide en plusieurs étapes. Par exemple, si on découpe une synchro en quatre étapes, il ne faut plus que 500 Mo de RAM et l’overhead doit être minime, non ?
Non ce sont des aléas réseaux normaux qui devrais être loggés en warning et pas en error.
Et bien code le et on en reparle…
2 Likes
Chiche (mais d’abord je termine ma thèse)
1 Like