Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
utilisateurs:zarmu:systemd [Le 28/09/2016, 06:38] zarmu [Personnaliser un fichier de configuration Systemd] |
utilisateurs:zarmu:systemd [Le 11/09/2022, 13:14] (Version actuelle) moths-art Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892) |
||
---|---|---|---|
Ligne 20: | Ligne 20: | ||
Il est généralement utilisé dans un [[:terminal]]: | Il est généralement utilisé dans un [[:terminal]]: | ||
<code>systemctl ACTION <Nom_du_service>.service</code> | <code>systemctl ACTION <Nom_du_service>.service</code> | ||
- | Où | + | Où |
* ACTION sera la commande que l'on souhaite appliquer à la dite unité: | * ACTION sera la commande que l'on souhaite appliquer à la dite unité: | ||
* // start // : démarrer le service | * // start // : démarrer le service | ||
Ligne 29: | Ligne 29: | ||
* <Nom_du_service> est le nom du service visé. | * <Nom_du_service> est le nom du service visé. | ||
- | Quelle que soit l'action menée sur un service, au prochain démarrage de la machine celui-ci devrait retrouver le status qui lui a été [[#Modifier l'exécution d'un service|défini par défaut]]. | + | Quelle que soit l'action menée sur un service, au prochain démarrage de la machine celui-ci devrait retrouver le status qui lui a été [[#Modifier l'exécution d'un service|défini par défaut]]. |
<note>Il n'est pas nécessaire d'utiliser sudo devant ces commandes. Systemctl vous demandera votre mot de passe root en cas de besoin (presque à chaque fois, donc)</note> | <note>Il n'est pas nécessaire d'utiliser sudo devant ces commandes. Systemctl vous demandera votre mot de passe root en cas de besoin (presque à chaque fois, donc)</note> | ||
Ligne 86: | Ligne 86: | ||
* Un service de type **oneshot** est similaire à un service de type **simple**. Cependant, systemd attend que le processus se termine avant de continuer ses traitements. **Ce type de service est typiquement utilisé comme équivalent aux commandes lancées au démarrage via les scripts d'init system V**. Cela permet à systemd de remplacer ce mécanisme. De ce fait, avec systemd des nouveaux services apparaissent, alors qu'ils auraient été simplement des scripts d'init avec SysVinit. | * Un service de type **oneshot** est similaire à un service de type **simple**. Cependant, systemd attend que le processus se termine avant de continuer ses traitements. **Ce type de service est typiquement utilisé comme équivalent aux commandes lancées au démarrage via les scripts d'init system V**. Cela permet à systemd de remplacer ce mécanisme. De ce fait, avec systemd des nouveaux services apparaissent, alors qu'ils auraient été simplement des scripts d'init avec SysVinit. | ||
* Un service de type **dbus** est similaire à un service de type **simple**. Cependant, le processus du service doit obtenir un nom via D-Bus. systemd pourra alors traiter les autres unités. | * Un service de type **dbus** est similaire à un service de type **simple**. Cependant, le processus du service doit obtenir un nom via D-Bus. systemd pourra alors traiter les autres unités. | ||
- | * Un service de type **notify** est similaire à un service de type "simple". Cependant, c'est le processus du service qui avertira systemd (via la fonction sd_notfy(3)) qu'il peut traiter les autres unités. | + | * Un service de type **notify** est similaire à un service de type **simple**. Cependant, c'est le processus du service qui avertira systemd (via la fonction sd_notfy(3)) qu'il peut traiter les autres unités. |
===Exemple de service de type "oneshot"=== | ===Exemple de service de type "oneshot"=== | ||
Ligne 96: | Ligne 96: | ||
RemainAfterExit=yes | RemainAfterExit=yes | ||
ExecStart=/usr/libexec/iptables.init start | ExecStart=/usr/libexec/iptables.init start | ||
- | ExecStop=/usr/libexec/iptables.init stop | + | ExecStop=/usr/libexec/iptables.init stop |
</file> | </file> | ||
Ligne 131: | Ligne 131: | ||
[Install] | [Install] | ||
WantedBy=multi-user.target | WantedBy=multi-user.target | ||
- | </file> | + | </file> |
* ''Description'' permet de donner une description du service qui apparaîtra lors de l'utilisation de la commande ''systemctl status <nom_du_service>'' | * ''Description'' permet de donner une description du service qui apparaîtra lors de l'utilisation de la commande ''systemctl status <nom_du_service>'' | ||
* ''After'' permet d'indiquer quel pré-requis est nécessaire pour le fonctionnement du service. Ici, on indique qu'il faut attendre que l'ordinateur ait accès à Internet pour lancer le daemon. FIXME **à vérifier :** Si l'accès à Internet est perdu, le service est arrêté automatiquement.\\ | * ''After'' permet d'indiquer quel pré-requis est nécessaire pour le fonctionnement du service. Ici, on indique qu'il faut attendre que l'ordinateur ait accès à Internet pour lancer le daemon. FIXME **à vérifier :** Si l'accès à Internet est perdu, le service est arrêté automatiquement.\\ | ||
- | Pour connaitre les dépendances d'une unité, tapez dans un [[:terminal]]: | ||
- | <code>systemctl list-dependencies [<unit>] </code> | ||
* ''Type'' permet de specifier le type de service | * ''Type'' permet de specifier le type de service | ||
* ''User'', ''Group'' et ''Umask'' permet d'identifier qui est le propriaitaire du processus et donc les attributs des fichiers téléchargés. Ici, les fichiers téléchargés seront accessibles en Lecture/Ecriture à l'utilisateur ''Deluge'' et aux membres du groupe ''Deluge'' et invisibles aux autres utilisateurs du système. | * ''User'', ''Group'' et ''Umask'' permet d'identifier qui est le propriaitaire du processus et donc les attributs des fichiers téléchargés. Ici, les fichiers téléchargés seront accessibles en Lecture/Ecriture à l'utilisateur ''Deluge'' et aux membres du groupe ''Deluge'' et invisibles aux autres utilisateurs du système. | ||
Ligne 143: | Ligne 141: | ||
\\ | \\ | ||
+ | ===Exemple de service modèle=== | ||
+ | Il est possible de creer plusieurs services à partir d'un même modèle. Par exemple, la gestion des consoles est gérée par un seul modèle ''getty@.service'' qui est décliné en ''getty@tty1.service'', ''getty@tty2.service'', etc pour chacune des consoles tty de votre machine. On peut aussi imaginer des services où chaque instance correspond à un utilisateur de la machine. Par exemple, on peut lancer le service syncthing@.service pour synchroniser en parallèle avec [[:syncthing]] les fichiers de Toto, Gerard et Milou : | ||
+ | |||
+ | <file txt syncthing@.service> | ||
+ | [Unit] | ||
+ | Description=Syncthing - Open Source Continuous File Synchronization for %I | ||
+ | Documentation=man:syncthing(1) | ||
+ | After=network.target | ||
+ | Wants=syncthing-inotify@.service | ||
+ | |||
+ | [Service] | ||
+ | User=%i | ||
+ | ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0 | ||
+ | Restart=on-failure | ||
+ | SuccessExitStatus=3 4 | ||
+ | RestartForceExitStatus=3 4 | ||
+ | UMask=0002 | ||
+ | |||
+ | [Install] | ||
+ | WantedBy=multi-user.target | ||
+ | </file> | ||
+ | |||
+ | * ''Wants'' permet de spécifier une dépendance. Pour connaître les dépendances d'une unité, tapez dans un [[:terminal]]: | ||
+ | <code>systemctl list-dependencies [<unit>] </code> | ||
+ | * Ici, le ''User'' est ''%i'', soit l'argument qui est passé lors de l'activation du service. Pour créer toute les instances du service pour Toto, Gerard et Milou, il faudra avoir tapé une fois : | ||
+ | <code>systemctl enable syncthing@Toto.service | ||
+ | systemctl enable syncthing@Gerard.service | ||
+ | systemctl enable syncthing@Milou.service | ||
+ | </code> | ||
- | FIXME **Il existe un toto dans le wiki Ubuntu [[:creer_un_service_avec_systemd]] mais il ne me semble pas complet** Je serai d'avis de le supprimer une fois cette page mise en ligne car il fait également doublon avec la modif que j'ai apporté sur la page de [[:deluge]]. | ||
===== Les targets ===== | ===== Les targets ===== | ||