Duniter "saute" régulièrement

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 Like

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

Merci pour ce script…

Avec Yunohost ça fonctionne nickel :wink:

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

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

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

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. :slight_smile: :+1:

Il te faut mettre à jour le paquet et le service systemd sera installé et activé.
La mise à jour en 1.8.0 a été fait il y a 23 jours.
L’ajout du service systemd a été fait il y a cinq jours.

1 Like

Ok ! J’avais vraiment pas compris, effectivement j’ai fait la mise à jours il y a 3 semaines mais sans passer par un paquet YunoHost, j’ai fait via la version ARM…
Bon ok je refais avec cette version, c’est CooL ! MERCI :slight_smile:

Salut, j’ai fait la mise à jour avec le paquet hier soir, effectivement je n’ai pas eu à lancer moi-même Duniter avec la commande duniter start ou webrestart.

Par contre ce matin le Raspberry Pi est encore en mode « veille », obligé d’éteindre et de le relancer.
Je pense qu’il faut que j’essaie de supprimer mon noeud pour voir si ça vient de là ou d’autre chose d’installé dessus ?..

Merci beaucoup pour ton aide.
Bonne journée. :slight_smile:

Étrange, cette nuit mon nœud n’a pas été redémarré automatiquement avec le service systemd que j’ai mis en place. Il me semble qu’il a déjà été redémarré depuis que je l’ai mis en place.

Cette fois le nœud n’a pas dû retourner de message d’erreur et n’a pas été redémarré avec la règle :

Restart=on-failure

pour que ça redémarre même quand le service ne quitte pas avec une sortie d’erreur (exit_code > 0). Il est possible de mettre :

Restart=always

Pour références, il a aussi un bug dans systemd :

2 Likes

Salut, merci pour l’info, je viens de modifier le fichier pour mettre Restart=always et je fais un reboot.
Ça sera la surprise si ça va tenir ou pas, je te tiens au courant. :slight_smile:
Merci encore :+1:


Bon j’édite ce post, car de bon matin le Pi est de nouveau en mode « veille »…
Je vais désinstaller Duniter pour voir si le phénomène vient de là ou pas car ça m’ennuie que mes sites soient accessibles par intermittence.

Merci pour l’aide, c’est sympa. :slight_smile: :+1:

Bon, en désinstallant Duniter, le Raspberry Pi tourne normalement, il ne se met plus dans cet état de « veille »…
J’ai donc bien un soucis malgré X réglages qui rend incompatible Duniter sur Raspberry Pi 3 + YunoHost + Diverses App installées en parallèle.

A noter quand même, le fait d’avoir rajouté un disque dur SSD sur le Pi et d’augmenter considérablement la mémoire Swap a permis d’arriver à synchroniser le noeud, chose que je n’arrivais plus à faire depuis très longtemps en configuration classique car quasiment toute la RAM était occupée par les autres App installées, du coup avec Duniter en + impossible de synchro… il y a donc une amélioration.

Ce que je ne comprends pas, c’est que les 10 premiers jours où j’avais installé Duniter 1.8, c’était stable, j’étais même impressionné de voir que ça tenait x jours sans se désynchroniser…
A voir, je tenterais éventuellement ma chance lors d’une prochaine mise à jours de Duniter. :slight_smile: :+1:

Pourquoi ne souhaites-tu pas que ton nœud Duniter v1 redémarre automatiquement en cas de crash ? Cherches-tu activement la source du crash ? Ce choix handicape ton instance WotWizard pour pas grand-chose, n’est-ce pas ? Je doute que le temps dédié à ces redémarrages soit rentable dans ton organisation.
Pour ma part, j’observe régulièrement mon nœud crasher et redémarrer automatiquement. Par contre, les logs ne me permettent pas d’en savoir plus.

Pourquoi je ne redémarre pas automatiquement Duniter est un autre sujet. Mais de toute façon wotwizard est connecté à mon nœud membre et idéalement je devrais découpler ces deux aspects. Sauf que garder 8 Go de RAM libre pour les pics de consommation de Duniter ne me plait pas particulièrement, et je ne peux pas le faire deux fois sur le même serveur.

Par rapport à l’utilisation de mon temps, c’est vrai que je pourrais arrêter totalement mes services v1. J’ai déjà arrêté Datajune, bientôt le tour de wotwizard et Duniter ?

My node just crashed:

Mar 12 10:47:25 moulinette node[751907]: (node:751907) Warning: Accessing non-existent property 'padLevels' of module exports inside circular dependency
Mar 12 10:47:25 moulinette node[751907]: (Use `node --trace-warnings ...` to show where the warning was created)
Mar 12 10:47:25 moulinette node[751907]: Starting g1 daemon...
Mar 12 10:47:26 moulinette node[751907]: g1 daemon started. PID: 751923

I added --trace-warnings to Node.js execution to see if I get more info.
Curiously padLevels is only used into winston lib.
I am trying with winston bumped from v2.3.1 to v2.4.7 to see.

Actually, this is just a warning, I can’t say if this is the reason for the crash.

1 Like