Lancer automatiquement Duniter au démarrage

Pour emerge je ne vais pas pouvoir t’aider avec Gentoo, mon serveur dédié est sous AlpineLinux qui utilise également OpenRC. J’ai simplement téléchargé/décompressé le .tar.gz, installé yarn puis ajouté sqlite3, pluggé duniter-ui et roulez jeunesse.

2 « J'aime »

Oui effectivement, je suis tombé sur ce problème aussi suite au bug de la commande plug. Des correctifs sont présents dans ce commit mergé dans la branche 1.6, qui devrait donc fonctionner pour @sveyret.

1 « J'aime »

Merci pour ta contribution !

Je suis en train de tester ton script systemd sur Ubuntu 16.04 (en l’adaptant à ma config…).

J’ai ajouté la directive

WorkingDirectory=[chemin du dossier duniter]

sinon duniter ne trouve pas la commande “webstart”.

Mais il ne fonctionne pas :disappointed_relieved:

Quand duniter tente de lancer

#!/usr/bin/env node

j’ai le message

/usr/bin/env : "node": Aucun fichier ou dossier de ce type

Une idée ?

[edit]
Il faut mettre le chemin complet de la commande “node” devant les commandes duniter et le script fonctionne !

Sauf que le noeud lancé par systemd :

  • Voit son interface web complètement cassé (pas de binding angular, des variables comme {{ title }} apparaissent).
  • Aucune API réseau n’est publiée, ni WS2P , ni BMA… Seule l’accès à localhost:9220 pour l’interface.

C’est pas gagné…

Je suis aussi sur le salon de discussion XMPP pour deboguer plus vite si tu es dispo…

Bonjour,

Où se trouve le salon XMPP ? J’ai Pidgin, je devrais pouvoir m’y connecter…

As-tu bien la dernière version du script, celle que l’on trouve ici :

Parce que ce script appelle le script duniter qui se trouve normalement dans /usr/bin, donc si le service ne démarre pas, c’est peut-être que le script ne démarre pas, même à la main.
Sinon, le script est prévu pour être exécuté par l’utilisateur duniter:duniter, dans son répertoire principal /var/lib/duniter. Si tu n’as pas modifié cela, ça ne fonctionnera pas non plus (note que l’installation Ubuntu a été modifié pour préparer cela dans la prochaine version).

Le salon xmpp : https://duniter.org/fr/contact/

Oui, j’ai adapté le script à mon utilisateur, à l’endroit où j’ai compilé Duniter pour mon netbook 32bits.
Le script fonctionne, mais il manque quelquechose dans l’environnement d’exécution qui fait que Duniter ne retrouve pas ses petits.
Note aussi que Duniter se lance, mais ne crée pas de fichier de logs… Donc pas facile à déboguer !

[EDIT]
Problème résolu !

Voici le script de démarrage pour systemd pour une installation manuelle de Duniter à partir des sources. Nodejs est géré par NVM, ce qui nécessite de préciser le chemin où se trouve la commande node.

[Unit]
Description=Duniter g1-test node
After=network.target

[Service]
# Should be set to web in order to start with web GUI
Environment="DUNITER_WEB=web"
Environment="DUNITER_HOME=/home/vit/.config/duniter"
Environment="DUNITER_DATA=duniter_default"

# If using a key file, DUNITER_OPTS can be defined like so:
#Environment="DUNITER_OPTS=--keyfile /etc/duniter/keys.yml"
Environment="DUNITER_OPTS="

# NVM and NODEJS
Environment=NODE_VERSION=6
Environment=NODE_ENV=production
Environment=PATH=/home/vit/.nvm/versions/node/v6.11.4/bin

Group=vit
User=vit
Type=forking

# Duniter install path
WorkingDirectory=/home/vit/Logiciels/duniter-g1-test

# Commands
ExecStart=/home/vit/Logiciels/duniter-g1-test/bin/duniter ${DUNITER_WEB}start --home ${DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS
ExecReload=/home/vit/Logiciels/duniter-g1-test/bin/duniter ${DUNITER_WEB}restart --home ${DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS
ExecStop=/home/vit/Logiciels/duniter-g1-test/bin/duniter stop --home ${DUNITER_HOME} --mdb ${DUNITER_DATA}
Restart=on-failure

[Install]
WantedBy=multi-user.target

J’ajouterai un modèle de script dans le wiki du site duniter.org.

Un message a été intégré dans un sujet existant : Build des releases duniter dans Docker

@sveyret afin de séparer les sujet j’ai migrer les messages relatif au build des releases dans un nouveau thread :wink:

1 « J'aime »

@sveyret Il ne reste plus que cette MR a traiter avant de pouvoir livrer la 1.6 je vais donc tester ça ce soir :slight_smile:

@vit je crois que tu a déjà pas mal testé, tu peut nous faire un point ? merci

EDIT : @sveyret je me suis permis de remerger la branche 1.6 dans StartUp qu’on puisse tester avec tout les derniers changements :wink:

J’ai déjà ajouté un article dans le wiki. S’il a besoin de précisions, dites le moi…

https://duniter.org/fr/wiki/duniter/lancement-au-boot/

1 « J'aime »

@sveyret bon ça ne marche pas chez moi ou alors je n’est pas compris ce qu’il faut faire, voici ce que j’ai fait :

J’ai créer une release de test sur ta branche StartUp : https://git.duniter.org/nodes/typescript/duniter/-/jobs/1450

j’ai installer le paquet deb version server, j’ai lancer duniter avec le profil par défaut, puis j’ai redémarré le pc, et duniter ne s’est pas relancé au demarrage, j’en conclu que soit ce n’est pas automatique soit ça ne fonctionne pas ?

Bah ! C’est moche ! :wink:

Je vais regarder ce qu’il y a à modifier (adapter) d’ici demain matin (si toutefois il y a quelque chose à faire).

Non, par défaut, le démarrage automatique n’est pas activé. Il faut que tu le fasses à la main. Si je ne me trompe pas, sur systemd, la commande est :

systemctl enable duniter.service

Et bien moi, je me suis permis de supprimer ce merge, réorganiser les commits et re-baser sur la nouvelle branche 1.6. Le résultat est presque le même, mais l’historique est beaucoup plus clair, non ? :wink:

Certaines modifications avaient été perdues lors du merge et donc il est possible que le service n’ait pas été installé chez toi. Avec les modifications que j’ai apportées maintenant, ça devrait être bon. J’ai vérifié que tout fonctionnait bien jusqu’à la livraison, que les fichiers étaient bien présents dans les binaires livrés, mais je n’ai pas encore fait de test d’installation, et ne pourrai probablement pas en faire avant le weekend.

3 « J'aime »

Faut vraiment que j’apprenne a faire ça :sweat_smile: 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 :slight_smile:

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… :relieved:

3 « J'aime »

Félicitations @sveyret ça fonctionne nickel chez moi, duniter se lance automatiquement après redémarrage :slight_smile:

faudra qu’on pense a rajouter dans le wiki comment activer cette feature :wink:

de mon coté c’est bon pour merger.

1 « J'aime »

J’ai prévu d’ajouter les informations nécessaires dans la documentation dès que la 1.6 sera sortie…

1 « J'aime »

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 !

2 « J'aime »

4 messages ont été déplacés vers un nouveau sujet : Tests des pre-releases

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).

1 « J'aime »