Hello world systemd

Support Debian
#1

Bonjour à tous,

J’ai lu pas mal de pages de manuel systemd, j’ai aussi consulté des blogs et autres ressources, pas moyen de créer un service perso.

J’ai commencé petit avec un script “hello world” :

et voici le script qui part ailleurs fonctionne dans la console :

C’est là que ça se corse : console en root

le status :

enfin le journal :

Mais bref : le scrit ne passe pas, pourtant il s’exécute manuellement, n’a pas besoin de permission root ou autre. J’avais essayé le type=simple avant type=forking, mais en fouillant je suis tombé sur un message disant que pour un script shell, type=forking est nécessaire. Bref, je suis sûr qu’il me manque un petit bout de truc quelque part, mais je ne trouve pas où et c’est assez frustrant.

Si vous avez une idée pour me débloquer, je suis preneur :slight_smile:

#2

Salut
Puisque tu envois un script qui est dans ton home, as tu essayé de le faire en mode user ?
https://wiki.archlinux.fr/Systemd/utilisateur
Dans ton home, dans ~/.config/systemd/user

les commande systemctl sont alors lancées en mode user: systemctl --user

Exemple je me suis bricolé un service alsa

systemctl --user status alsa-restore.service
● alsa-restore.service - Ma restauration des niveaux de son alsa
   Loaded: loaded (/home/guy/.config/systemd/user/alsa-restore.service; enabled;
   Active: inactive (dead) since Wed 2018-07-25 09:10:34 CEST; 27min ago
  Process: 1518 ExecStart=/usr/sbin/alsactl -f /home/guy/.config/alsa/save.asoun
  Process: 1315 ExecStartPre=/bin/sleep 15 (code=exited, status=0/SUCCESS)
 Main PID: 1518 (code=exited, status=0/SUCCESS)

juil. 25 09:10:18 debian systemd[1304]: Starting Ma restauration des niveaux de son
juil. 25 09:10:33 debian systemd[1304]: Started Ma restauration des niveaux de son

Pour toi, le pb étant dans quel tty systemd va-t-il écrire?

#3

Ah non pas du tout, ce n’est pas lié au langage du programme à faire exécuter via systemd. J’ai des services systemd qui font tourner de bêtes scripts shell (même si les commandes dans ces scripts font appel à des commandes externes au shell, et donc, font de facto des forks), ce sont des type=simple
La seule fois où j’ai dû utiliser type=forking c’était pour un script shell qui lance un exécutable java en lui passant les bonnes options.

#4

Bonjour à tous,

Je reviens sur le sujet.

Merci grandtoubab pour les conseils.

Voici à quoi ressemble mon test maintenant :

J’ai remplacé la partie tty par une simple redirection vers un fichier pour ne pas confondre les problèmes.

Le fichier de conf pour systemd ressemble à ça :

et voici le script qui part ailleurs fonctionne dans la console :

J’ai remplacé le nom du service test par montest pour éviter un éventuel nom réservé.

Test du script seul :

Par contre, à priori, je n’arrive pas à faire fonctionner le systemd :

Console utilisateur classique :

Avant de répondre, il me demande le mot de passe root dans une fenêtre de type popup, ce que je ne comprends pas très bien.
Du coup, s’il execute la commande en root, est-ce qu’il cherche bien dans : “~/.config/systemd/user” et pas dans un truc qui serait : “/root/…” ?

Console en root :

Je m’en doutais, mais en root, il ne trouve pas le service dans le répertoire “user”.

En fouillant l’aide de systemd ou sur le web, pas moyen de trouver un fichier de config dans lequel je lui dit de regarder dans : ~/.config/systemd/user pour qu’il puisse trouver : montest.service
Je n’ai pas non plus trouvé de moyen pour que mon utilisateur puisse faire lui même un “systemctl start xxx” lui même.

Merci Sputnik93, j’ai remplacé “forking” par “oneshot” qui me semblait moins source d’erreurs.

En tous cas, je suis toujours bloqué…

Des idées ?

#5

avec tes explications,je ne comprends pas si tu as véritablement utilisé le mode user
en considérant que ce soit bien le cas , le service se lancerait depuis une fenetre terminal de ton utilisateur

systemctl --user start montest.service

De même pour vérifier l’état, exemple d’un service alsa perso que j’ai déclaré en mode user

 systemctl --user status alsa-restore
● alsa-restore.service - Ma restauration des niveaux de son alsa
   Loaded: loaded (/home/guy/.config/systemd/user/alsa-restore.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2018-08-23 09:25:17 CEST; 16min ago
  Process: 2681 ExecStart=/usr/sbin/alsactl -f /home/guy/.config/alsa/save.asound.state restore 0 (code=exited, status=0/SUCCESS)
  Process: 2516 ExecStartPre=/bin/sleep 15 (code=exited, status=0/SUCCESS)
 Main PID: 2681 (code=exited, status=0/SUCCESS)

août 23 09:25:02 debian systemd[2461]: Starting Ma restauration des niveaux de son alsa...
août 23 09:25:17 debian systemd[2461]: Started Ma restauration des niveaux de son alsa.
#6

Merci :smiley:

Effectivement, honte à moi, le retour à l’informatique n’est pas facile :frowning:

Voici les retours avec l’option --user :

Console en utilisateur lambda :

le status :

enfin le journal : en mode root, sinon pas moyen de l’afficher.

Mais bref : le scrit ne passe toujours pas, pourtant il s’exécute manuellement, n’a pas besoin de permission root ou autre.

Malgré les simplifications et modifications, le script ne tourne pas. Et le message “permission denied” me laisse perplexe. :slight_smile:

Sur d’autre discussions, je peux voir des personnes ajouter /bin/bash devant le script au niveau du ExecStart pour le service mais je ne vois pas bien à quoi cela sert, c’est une piste ?

#7

c’est surtout pour éviter de se prendre la tête avec les erreurs d’écriture dans le script car chaque shell a ses finesses
Donc autant etre cohérent et utiliser le bon shell
ça se vérifie dans les variables d’environnement

Exemple chez moi:

debian:~$ env | grep -i shell 
SHELL=/bin/bash

NB si tu donnais simplement le contenu intégral de ton script ça faciliterai les choses …par exemple dans un script il est toujours mieux de travailler en chemin absolu

ton script est il bien exécutable?
as tu fais chmod +x

#8

Oui le script fonctionne tout seul :

Le texte complet :

Test du script seul en console utilisateur :

#9

oui ok mais tu le lances avec la commande sh
Ce qui ne réponds pas à la question: "le script est il executable?"
pour vérifier

ls -ll /home/serveur/test.sh

s’il est exécutable tu dois voir le caractère x
On peut voir cinq lettres différentes. Voici leur signification :

d (Directory) : indique si l’élément est un dossier ;

l (Link) : indique si l’élément est un lien (raccourci) ;

r (Read) : indique si on peut lire l’élément ;

w (Write) : indique si on peut modifier l’élément ;

x (eXecute) : si c’est un fichier, « x » indique qu’on peut l’exécuter.

#10

Lorsque j’avais essayé de faire sh sur mon premier script, il m’avait envoyé bouler, ce que j’avais résolu en cochant exécutable dans les autorisations (je dis ça de tête, c’est pas très fiable du coup).
Je vérifie ce soir.

#11

Ok, alors, j’ai progressé.

Maintenant, effectivement, le service fonctionne.

J’ai essayé de changer la redirection vers le fichier en redirection vers tty et comme tu le disais, grandtoubab, il y a un soucis avec tty :thinking:

Le texte complet du script :

Test du script seul en console utilisateur :

“Hello world” apparait dans la même console.

Console en utilisateur lambda :

le status :

enfin le journal :

Bon, je pars me documenter sur systemd et tty.

Merci pour le coup de main.

#12

Une suggestion en passant…
Plutôt que de te prendre la tête avec systemd en user, pourquoi n’utilises-tu pas cron ??
1 - tu testes ton script bash dans un terminal
2 - crontab -e

ps: cron est géré par systemd.

#13

Bonsoir Verner,

En fait c’est la première solution que j’ai testé.

Prérequis pour suivre le reste : mon script doit se lancer au démarrage du pc, avec à minima un accès réseau voir d’autres pré-requis si java en a.

Voici tout ce que j’ai fait en détails, vous pourrez peut-être corriger certaines erreurs.

  1. Passer mes scripts sous cron
    Première déconvenue, cela n’a pas marché.
    J’ai essayé une ligne avec le mot clé @reboot : mon appli n’était pas détectée alors qu’elle se lance sans problème à la main.
    –> J’ai soupçonné un soucis d’ordre de lancement au boot.
    Pour essayer de débuger, j’ai voulu afficher mon script dans une console, j’ai donc essayé quelque chose du genre :
    xterm -hold -e sh monscript.sh
    –> Toujours des erreurs et pas de fenêtre xterm

  2. J’ai essayé de rediriger mon script dans une fenêtre tty, de la même manière que dans le dernier “hello world” que j’ai présenté :
    –> Toujours pas de fenêtre.

  3. J’ai compris de mes lectures en diagonale de plusieurs articles que systemd gérait plus précisément à quel moment se lançaient les scripts notamment au boot et que systemd semble se démocratiser, j’ai donc décider d’essayer d’y passer.
    –> On est donc arrivé à ce post et j’essaie maintenant d’avance sur mon vrai problème, mais je suis content d’avoir réussi à créer mon premier service systemd fonctionnel.

En tout cas, merci à tous pour vos idées :smiley:

#14

Effectivement s’il y a un prérequis de connexion réseau, cron va manquer de flexibilité et systemd est adapté.
Mais comme ce n’est pas script user mais plutôt système, il faut peut-être placer le service directement dans /lib/systemd/system/, soit test.service et essayer:

sudo systemctl enable test.service

Peut-être essayer cette condition:

[Unit]
After=systemd-udevd.service network-pre.target systemd-sysctl.service

ps: déjà être sûr à 100% que le script bash appelé fonctionne correctement