Duniter "saute" régulièrement

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 J'aime

C’est quoi comme version ?

La version arm pour raspberry, pas la dernière.

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 !!! :slight_smile:

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 :slight_smile:
ç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 J'aimes

Ç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é :slight_smile:

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 ?..). :wink:

1 J'aime

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 :slight_smile: )
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 J'aimes

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 !!! :slight_smile:

1 J'aime

Bien reçu. Je transmets le log au prochain plantage.

Merci pour ce script…

Avec Yunohost ça fonctionne nickel :wink:

1 J'aime

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 :slight_smile:

2 J'aimes

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 J'aime

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 J'aimes

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 :slight_smile: