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 
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.
É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 :
- https://unix.stackexchange.com/questions/289629/systemd-restart-always-is-not-honored
- https://medium.com/@benmorel/creating-a-linux-service-with-systemd-611b5c8b91d6
- https://serverfault.com/questions/759764/systemd-does-not-restart-service-although-restart-always
- https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1839290
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.
Merci encore 
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.
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.
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