Depuis quelques temps, le serveur duniter installé sur mon rapsberry « saute » et s’arrête. Je suis obligé de refaire une sync et de le relancer manuellement. C’est chiant.
Quelqu’un saurait pourquoi ça fait ça ?
1 Like
C’est quoi comme version ?
Coucou,
J’ai le même souci sur la version “normal” sur mon serveur sous Debian, installé que pour ça.
Le process plante régulièrement (c’est arrivé il y a quelques jours d’ailleurs, faudrait voir si c’est arrivé en même temps que toi ?)
Du coup, j’ai planifié un CRON qui lance toutes les minutes un script bash qui relance le process s’il est arrêté.
ça fait longtemps que je voulais partager ça, donc je prends le temps aujourd’hui !!! 
Du coup, il faut :
Rajouter cette ligne dans le cron : “* * * * * /home/xxx_ton_user_xxx/check_up_duniter.sh”
Créer le script “/home/xxx_ton_user_xxx/check_up_duniter.sh” avec le contenu suivant :
#!/bin/bash
if [[ ! `pidof -s duniter_default` ]]; then
echo "--> Derniere LOG avant le crash"
tail -n 50 /root/.config/duniter/duniter_default/duniter.log
echo "--> RESTART duniter"
duniter webstart
fi
et voila
ça redémarre tout seul toutes les minutes max si besoin !
Pour pousser un peu le truc, on peut rajouter la ligne suivante au début du CRON : MAILTO=“xxxxxxx@tonmailcom”
et on reçoit un mail pour nous dire quand ça plante et redémarre ! (il faut bien-sur que le serveur puisse envoyer des mails, via EXIM par exemple…)
4 Likes
Ça a l’air bien ton système, je le tente sur un mois, je verrai si ça saute encore ou pas… Je te dirai.
Un grand merci en tout cas !
ça marche si c’est juste le service qui plante. Si il corrompt les données et s’échoue dans un fork comme ça m’arrive de temps en temps, là il faut refaire un reset et un sync en plus vu qu’il s’embourbe dans le revert, même demandé manuellement.
Yep, justement ça va m’aider à savoir si ça “saute” ou si ça se désynchronise. Si le phénomène recommence et que je suis obligé de refaire tout manuellement, ça ne changera rien,en revanche, si ça se reco tout seul grâce à ce petit script, c’est réglé
Pour l’instant ça marche bien, réponse définitive dans un mois…
Si tu peux récupérer les derniers logs au moment du plantage pour identifier la cause, ce serait l’idéal. Parce que la solution du cron, c’est utile pour maintenir le serveur sous perfusion, mais ça ne va pas nous aider à identifier un bug potentiel.
Logger aussi l’état de la machine (disque saturé ? mémoire saturée ? une mouche dans le ventilo ?..). 
1 Like
Bonne idée …
Du coup, j’ai rajouté une ligne histoire de recevoir un bout de log au moment du crash (toujours par mail dans mon cas )
donc voici mon nouveau script :
#!/bin/bash
if [[ ! `pidof -s duniter_default` ]]; then
echo "--> Derniere LOG avant le crash"
tail -n 50 /root/.config/duniter/duniter_default/duniter.log
echo "--> RESTART duniter"
duniter webstart
fi
A suivre au prochain plantage …
4 Likes
Par contre, le reste (disque, mémoire, …) est plus ou moins surveillé car c’est une VM dédiée qui est dans un datacenter de chez Online, et j’ai des rapports quotidiens.
Et donc y’a pas de mouche !!!
1 Like
Bien reçu. Je transmets le log au prochain plantage.
Merci pour ce script…
Avec Yunohost ça fonctionne nickel 
1 Like
Mes nœuds Duniter qui font tourner la Ğ1 sautent quasiment toutes les nuits depuis que le réseau est passé en v1.8.0.
Il se trouve que j’ai un nœud Ğ1 et un nœud Ğ1-test sur le même serveur, et la commande pidof -s duniter_default retourne toujours un pid lorsqu’un nœud s’est arrêté, car les deux processus ont le même nom. Du coup, j’ai renommé l’un des deux pour avoir l’état des deux séparément. Pour renommer, il faut utiliser un emplacement de dossier différent pour la base de données avec --mdb lors de toutes les manipulations du nœud :
-d, --mdb <name> Database name (defaults to "duniter_default").
Voici mon script avec le shell fish, que je place par exemple dans $HOME/restart_duniter.sh :
#!/bin/fish
if not pidof -s duniter_default;
duniter start
end
Puis, j’ajoute une ligne dans le crontab avec la commande crontab -e qui va tenter de redémarrer Duniter toutes les heures à zéro minute :
0 * * * * $HOME/duniter_restart.sh
Avant, je trouvais ça vraiment du bricolage, mais, je me rends compte que c’est plus possible, car Duniter crashe beaucoup trop souvent. Trouver l’origine de ce bug ne semble pas simple.
J’allais partir sur le fait que ça faisait bientôt plus d’un an que je ne souffrais plus d’interruption de mon noeud duniter quand je me suis souvenu que systemd gérait la continuité des services, je l’avais configuré à la main à l’époque car je crois que le paquet deb avait un soucis.
c’est toujours le cas ?
Une fois lancé en tant que service, pas besoin de scripts ou autres manipulations pour les non aguerris, ça juste marche 
2 Likes
Merci pour l’information. Je ne savais pas qu’on pouvait faire redémarrer un service s’il plantait avec systemd. C’est plus propre ainsi.
Un tutoriel qui en parle.
1 Like
Pour information, ce champ est déjà configuré ainsi dans le service systemd fournis dans le paquet Debian de Duniter.
Tout est très bien expliqué dans cette documentation rédigé par sveyret. Un grand merci pour ça !
J’ai finalisé ça pour le paquet Duniter. Ça devrait rendre un grand service aux utilisateurs de YunoHost.
Pour les distributions Debian-like, non-YunoHost, ne serait-il pas possible d’activer par défaut ce service systemd ? Les paquets officiels Debian font ce boulot en général.
Pour les distributions non-Debian, il faut installer et activer ce fichier à la mano.
4 Likes
C’est un parfait cas de contribution qui peut être réalisée par quelqu’un d’autre que moi, ça ne nécessite pas de rentrer dans la codebase de Duniter en lui-même 
Salut ! Merci pour ces liens.
Depuis que j’ai la version 1.8, effectivement Duniter est plus stable sur Raspberry Pi 3 via YunoHost.
Cependant cela arrive encore fréquemment de planter mais en plus ça me stop le Raspberry P, enfin plus précisément c’est comme s’il se mettait en veille… (lumière rouge fixe sur le Pi au lieu de diode verte qui clignote parce qu’il travaille).
Du coup j’ai tenté de suivre le tutoriel pour créer le fichier services systemd mais ça ne fonctionne pas.
Job for duniter.service failed because the control process exited with error code.
See "systemctl status duniter.service" and "journalctl -xe" for details.
systemctl status duniter.service renvoie :
Jul 04 14:25:37 NDD systemd[1]: **duniter.service: Unit entered failed state.**
Jul 04 14:25:37 NDD systemd[1]: **duniter.service: Failed with result 'exit-code'.**
Jul 04 14:25:37 NDD systemd[1]: duniter.service: Service hold-off time over, sched
Jul 04 14:25:37 NDD systemd[1]: Stopped Duniter node.
Jul 04 14:25:37 NDD systemd[1]: **duniter.service: Start request repeated too quickl**
Jul 04 14:25:37 NDD systemd[1]: **Failed to start Duniter node.**
Jul 04 14:25:37 NDD systemd[1]: **duniter.service: Unit entered failed state.**
Jul 04 14:25:37 NDD systemd[1]: **duniter.service: Failed with result 'exit-code'.**
journalctl -xe renvoie :
-- The result is failed.
Jul 04 14:32:04 NDD systemd[1]: **duniter.service: Unit entered fail**
Jul 04 14:32:04 NDD systemd[1]: **duniter.service: Failed with resul**
Jul 04 14:32:04 NDD systemd[1]: duniter.service: Service hold-off
Jul 04 14:32:04 NDD systemd[1]: Stopped Duniter node.
-- Subject: Unit duniter.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit duniter.service has finished shutting down.
Jul 04 14:32:04 NDD systemd[1]: **duniter.service: Start request rep**
Jul 04 14:32:04 NDD systemd[1]: **Failed to start Duniter node.**
-- Subject: Unit duniter.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit duniter.service has failed.
--
-- The result is failed.
Jul 04 14:32:04 NDD systemd[1]: **duniter.service: Unit entered fail**
Jul 04 14:32:04 NDD systemd[1]: **duniter.service: Failed with resul**
Jul 04 14:32:06 NDD CRON[2639]: pam_unix(cron:session): session cl
Bon j’ai adapté par exemple dans le tuto, le fichier a créer s’appelle duniter-g1-test.service moi je l’ai appelé duniter.service l’erreur peut-elle venir de là ?
Pour le group_user je ne savais pas quoi mettre j’ai mis admin ?
Je pensais que le nom de fichier était le cas où l’on utilisait la monnaie test ?
Bref sinon, je m’interroge est-ce que c’est Duniter qui plante et qui entraîne la « mise en veille » du Pi ? J’ai mis entre parenthèse car je ne sais pas si c’est son réel état, plus rien ne fonctionne y compris l’accès en SSH en local.
Ou est-ce que c’est YunoHost finalement qui plante et du coup ben forcément Duniter s’arrête ?
Mais bon avant de ré-installer un noeud, jamais eu ce souci, je pense donc pour la 1ère option.
Désolé pour ce post à rallonge, comme d’habitude je suis preneur de toute info vous venant à l’esprit.
Merci beaucoup ! 
1 Like
Je me suis occupé de gérer tout ça dans le paquet YunoHost. L’utilisateur et le groupe sont actuellement root. Tu n’as rien à faire à présent. Après, si tu modifies des choses, ça risque de pas se comporter comme prévu par le paquet.
Aucune idée. Ça doit être lié à ton installation.
1 Like
Ok, j’avais pas compris, en fait avec la dernière version 1.8 sur YunoHost j’ai déjà le fichier de créé ?
Quand je suis le lien du paquet YunoHost que tu as mis au-dessus, je ne comprends pas si je dois effectuer une action ou pas ?
Pour le coup, ça plante régulièrement en fait… faut-il que j’effectue une action particulière par rapport à ton lien concernant le paquet YunoHost ?
Merci pour ton aide.