Faut vraiment que j’apprenne a faire ça dsl j’avais besoin de tester ta branche hier soir avec les dernières évolutions alors j’ai fait comme j’ai l’habitude de faire, je comprend que ta méthode est mieux.
Merci je vais tester ça
Faut vraiment que j’apprenne a faire ça dsl j’avais besoin de tester ta branche hier soir avec les dernières évolutions alors j’ai fait comme j’ai l’habitude de faire, je comprend que ta méthode est mieux.
Merci je vais tester ça
Je vous ferai une petite formation avec grand plaisir, mais comme il est peu probable que l’on se rencontre, si ça en intéresse certains, j’essaierai de faire une petite vidéo pour expliquer tout ça. Enfin bon, si j’ai du temps…
Félicitations @sveyret ça fonctionne nickel chez moi, duniter se lance automatiquement après redémarrage
faudra qu’on pense a rajouter dans le wiki comment activer cette feature
de mon coté c’est bon pour merger.
J’ai prévu d’ajouter les informations nécessaires dans la documentation dès que la 1.6 sera sortie…
Je peut livrer une pré-release 1.6.15 dés ce soir tout est pret et fonctionnel pour. Faudra quand même attendre qu’elle fasse ses preuves sur le réseau avant de la déclarer officielle !
Salut tout le monde.
Merci pour cette contribution mais ça ne fonctionne pas chez moi. Je dispose d’une debian 64 bits sur laquelle j’ai installé duniter v1.6.17. J’ai activé le service duniter.service comme indiqué ici (sudo systemctl enable duniter.service) après (ou avant je ne sais plus) avoir sync le noeud avec l’utilisateur duniter (sudo -u duniter duniter sync) Le service se lance au démarrage et les commandes start/stop/status fonctionnent : le processus est bien lancé/stoppé (un ps -aux | grep “duniter” m’indique que le processus est bien lancé avec le user duniter). Par contre, le noeud est injoignable et n’enregistre pas de logs…Par contre, lorsque je lance le programme à la main (sudo -u duniter duniter start), pas de soucis, le noeud est joignable et enregistre ses logs.
Une idée d’où pourrait venir le problème ?
EDIT :
ooooooh ! Dans le fichier /lib/systemd/system/duniter.service, j’ai remplacé ExecStart=/usr/bin/duniter ${DUNITER_WEB}start --home ${DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS par ExecStart=/usr/bin/duniter start
paidge: et le service fonctionne
DU coup, j’y vais par tatonnement. Avec ${DUNITER_WEB}start ça marche mais en ajoutant –home ${DUNITER_HOME} ça ne fonctionne plus
Je pense que le sync a stocké les fichiers au mauvais endroit. En effet, je viens de lancer sudo -u duniter duniter sync g1.duniter.org 10901 --home /var/lib/duniter et j’ai l’impression qu’il vient de me créer le sous-dossier g1 dans .config/…Donc avant d’activer le service il faut sync le noeud mais en précisant le paramètre --home ? Ou alors y’a un truk que j’ai pas fait correctement ou dans le bon ordre. Pourtant j’ai suivi la doc à la lettre…
EDIT n°2 : En effet, je viens de lancer sudo find . -type d -name g1 :
./var/lib/duniter/.config/duniter/duniter_default/g1
./var/lib/duniter/duniter_default/g1
En effet, le mode service positionne par défaut un --home
et un --mdb
particuliers. Si tu veux pouvoir paramétrer ou voir les logs du service, il faut que tu utilises les mêmes paramètres quand tu exécute la commande duniter
.
Je te conseille de ne pas modifier le fichier livré dans /lib/systemd/system
, mais plutôt d’en créer un autre dans lequel tu ne fais que surcharger les valeurs que tu souhaites. Cela évitera que ta configuration se fasse écraser lors d’une prochaine montée en version (c’est la technique du drop-in, comme expliquée dans le guide d’installation).
Il vaut mieux éviter de lancer duniter avec sudo, essaie plutôt de te logger sous le user duniter (su - duniter) et de lancer les commandes directement à partir de ce user-là et sans sudo.
Après des heures d’investigation, j’ai trouvé d’où vient le problème :
Par défaut les options --home et --mdb de la commande sync valent respectivement $HOME/.config/duniter/ et duniter_default.
Lorsqu’on installe duniter à partir du .deb, l’utilisateur duniter est créé et son $HOME vaut /var/lib/duniter.
Donc si on fait un sync avec l’utilisateur duniter sans préciser l’option –home, duniter créera les fichiers dans /var/lib/duniter/.config/duniter/duniter_default
Or, de base, dans la configuration du service, le service se lance avec /usr/bin/duniter {DUNITER_WEB}start --home {DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS
Comme Environment=“DUNITER_HOME=/var/lib/duniter” et Environment=“DUNITER_DATA=duniter_default”,
duniter cherchera les fichiers dans /var/lib/duniter/duniter_default
Donc, soit il faut modifier, à la source dans le package duniter, le fichier /lib/systemd/system/duniter.service pour modifier les valeurs par défaut de DUNITER_HOME et DUNITER_DATA.
(en l’occurence, je pense que Environment=“DUNITER_HOME=/var/lib/duniter/.config/duniter”
devrait suffire)
Soit il faut améliorer la doc en précisant ces points
Je te conseille de ne pas modifier le fichier livré dans /lib/systemd/system, mais plutôt d’en créer un autre…
Oui merci, c’est ce que j’avais fait déjà pour lancer le service en mode webstart
@sveyret il faut que tu modifie ça dans ton script, car en effet par défaut Duniter créer les données dans $HOME/.config/duniter/ donc il faut que tu rajoute ce .config/duniter dans tons script
La doc précise déjà une partie de ces points. Il serait bien, par contre, de rajouter un paragraphe pour préciser les paramètres à utiliser pour --home
pour le cas où l’on veut lancer des commandes manuelles comme la synchronisation.
La doc précise les options --home et --mdb de la commande sync…Mais à aucun endroit dans “activez-le-demarrage-automatique” il n’est précisé qu’il ne faut pas utiliser le --home par défaut…Si, comme moi, qqun fait tout par défaut, et bah ça marche pas, il comprend pas pkoi et il cherche presque 8h d’où vient le pb
Tu crois ? Ça n’a pas tellement de sens (à mon avis) de créer un répertoire caché dans le cas du fonctionnement en mode service. Les fichiers sont dans /var/lib
qui est le défaut pour les bases de données sous Linux.
Dans le cadre d’un fonctionnement normal, il faut par contre que la base de données se trouve dans .config
pour ne pas polluer le répertoire d’un compte qui sert à plein de choses.
Oui mais cela rend l’usage de la feature “lancement automatique au démarrage” plsu user friendly, tu voit bien paidge a perdu plusieurs heures juste a cause de ça, et même si on l’écris dans la doc y en a plein d’autres qui galèreront…
A mon avis, y’a juste à mettre à jour la ligne :
Environment="DUNITER_HOME=/var/lib/duniter"
Par :
Environment="DUNITER_HOME=/var/lib/duniter/.config/duniter"
Et hop, ça m’aurait fait gagner une journée de boulot
Malheureusement, je pêche de ne jamais avoir lancé un nœud Duniter. Du coup, il y a certaines choses que je ne vois pas (encore). Enfin, normalement, ce problème devrait bientôt être réglé.
OK, je modifierai cela, alors.
Quelle idée, il suffisait de poser la question !
Oui, c’est bien cela. Je ferai une MR dès que possible. Désolé pour le temps perdu !
Sinon, pour que ça marche à tous les coups et que ça reste propre quand même, est-ce que vous croyez que ça poserait des problèmes de créer un lien de ~/.config/duniter
vers ~
?
J’en ai parlé à un collègue ce midi et c’est une idée à laquelle on a pensé en effet
Est-ce qu’il faut que ce soit modifié pour la release de la 1.6 ? Donc que je m’en occupe ce soir ?