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:13] 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 53: | Ligne 53: | ||
| ====Modifier l'exécution d'un service==== | ====Modifier l'exécution d'un service==== | ||
| - | |||
| - | Comme [[:Upstart]], systemd utilise des fichiers de configuration correspondant aux différents services à manipuler.\\ | ||
| - | Ces fichiers de configuration se trouvent dans **/etc/systemd/system/** et permettent d'indiquer les conditions d'activation ou désactivation d'un service, leur propriétaire, etc. | ||
| - | <note important>Ce dossier étant essentiel au bon fonctionnement de votre système, il est conseillé d'en faire une sauvegarde avant toute modification de fichier.\\ | ||
| - | Dans un [[:terminal]] saisissez: | ||
| - | <code>sudo cp -r /etc/systemd/system /etc/systemd/system.save$(date +%Y%m%d)</code></note> | ||
| Pour desactiver un service, il faut taper : | Pour desactiver un service, il faut taper : | ||
| Ligne 80: | Ligne 74: | ||
| [[:tutoriel:comment_installer_un_paquet|Installez les paquets]] **[[apt>systemd-ui|systemd-ui]]** | [[:tutoriel:comment_installer_un_paquet|Installez les paquets]] **[[apt>systemd-ui|systemd-ui]]** | ||
| ==== Personnaliser un fichier de configuration Systemd==== | ==== Personnaliser un fichier de configuration Systemd==== | ||
| + | Comme [[:Upstart]], systemd utilise des fichiers de configuration correspondant aux différents services à manipuler.\\ | ||
| + | Ces fichiers de configuration se trouvent dans **/etc/systemd/system/** et permettent d'indiquer les conditions d'activation ou désactivation d'un service, leur propriétaire, etc. | ||
| + | |||
| + | <note important>Ce dossier étant essentiel au bon fonctionnement de votre système, il est conseillé d'en faire une sauvegarde avant toute modification de fichier.\\ | ||
| + | Dans un [[:terminal]] saisissez: | ||
| + | <code>sudo cp -r /etc/systemd/system /etc/systemd/system.save$(date +%Y%m%d)</code></note> | ||
| + | |||
| Systemd defini differents types de services : | Systemd defini differents types de services : | ||
| * Un service de type **simple** (type par défaut) lance un processus principal. Dans le cas où ce processus offre une fonctionnalité à d'autre processus sur le système, ses canaux de communication doivent être installés avant que le processus principal soit démarré. Ce qui est rendu possible par l'activation des sockets, et autres canaux de communication. Ainsi, systemd peut traiter les autres unités sans se préoccuper de la fin du lancement d'une unité de type "simple". | * Un service de type **simple** (type par défaut) lance un processus principal. Dans le cas où ce processus offre une fonctionnalité à d'autre processus sur le système, ses canaux de communication doivent être installés avant que le processus principal soit démarré. Ce qui est rendu possible par l'activation des sockets, et autres canaux de communication. Ainsi, systemd peut traiter les autres unités sans se préoccuper de la fin du lancement d'une unité de type "simple". | ||
| Ligne 85: | 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"=== | ||
| - | Un exemple est le service iptables. Ci-dessous, je donne un extrait de son fichier de configuration : | + | Un exemple est le service iptables. Voici un extrait de son fichier de configuration : |
| <file> | <file> | ||
| Ligne 95: | 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> | ||
| - | * ''ExecStart'' permet d'indiquer la commande à exécuter au lancement du service. Ce paramètre est obligatoire pour tout les types de service.\\ | + | * ''ExecStart'' permet d'indiquer la commande à exécuter au lancement du service. Ce paramètre est obligatoire pour tout les types de service. |
| - | * ''ExecStop'' permet d'indiquer une commande a exécuter pour arrêter le service. Ce paramètre est facultatif.\\ | + | * ''ExecStop'' permet d'indiquer une commande a exécuter pour arrêter le service. Ce paramètre est facultatif. |
| - | * ''RemainAfterExit'' à la valeur "yes" permet d'indiquer que quand la commande de lancement (ExecStart) est terminée, le service est considéré comme toujours lancé. Ce paramètre est très utile pour les services de type "oneshot" qui exécutent une commande à leur lancement (ExecStart) sans qu'il y ait un processus spécifique qui reste en exécution.\\ | + | * ''RemainAfterExit'' à la valeur "yes" permet d'indiquer que quand la commande de lancement (ExecStart) est terminée, le service est considéré comme toujours lancé. Ce paramètre est très utile pour les services de type "oneshot" qui exécutent une commande à leur lancement (ExecStart) sans qu'il y ait un processus spécifique qui reste en exécution. |
| \\ | \\ | ||
| * A son lancement, la commande /usr/libexec/iptables.init start est exécutée. Cette commande va permettre de charger des modules iptables et les règles iptables que le modules netfilter du noyau linux va prendre en compte. | * A son lancement, la commande /usr/libexec/iptables.init start est exécutée. Cette commande va permettre de charger des modules iptables et les règles iptables que le modules netfilter du noyau linux va prendre en compte. | ||
| Ligne 106: | Ligne 107: | ||
| * Le service iptables continuera d'apparaitre comme actif après la fin de la commande /usr/libexec/iptables.init start et jusqu’à ce qu'il soit explicitement arrêté. | * Le service iptables continuera d'apparaitre comme actif après la fin de la commande /usr/libexec/iptables.init start et jusqu’à ce qu'il soit explicitement arrêté. | ||
| + | ===Exemple de service de type "simple"=== | ||
| + | Un exemple est le service deluged qui permet de lancer le service correspondant à la version deamon du client bit-torrent [[:deluge]]. | ||
| + | <file txt /etc/systemd/system/deluged.service> | ||
| + | [Unit] | ||
| + | Description=Deluge Bittorrent Client Daemon | ||
| + | After=network-online.target | ||
| + | [Service] | ||
| + | Type=simple | ||
| + | User=deluge | ||
| + | Group=deluge | ||
| + | UMask=007 | ||
| - | Pour connaitre les dépendances d'une unité, tapez dans un [[:terminal]]: | + | ExecStart=/usr/bin/deluged -d |
| + | |||
| + | Restart=on-failure | ||
| + | |||
| + | # Configures the time to wait before service is stopped forcefully. | ||
| + | TimeoutStopSec=300 | ||
| + | |||
| + | [Install] | ||
| + | WantedBy=multi-user.target | ||
| + | </file> | ||
| + | |||
| + | * ''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.\\ | ||
| + | * ''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. | ||
| + | * ''Restart'' permet de relancer le service automatiquement en cas de plantage. | ||
| + | * ''WantedBy'' permet de spécifier dans quel Target doit être actif le service. Ici, en spécifiant ''multi-user.target'', le service est actif dans les Runlevels 2, 3, 4 et 5 | ||
| + | \\ | ||
| + | |||
| + | ===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> | <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 ===== | ||