Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

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ù  +
   * 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 =====
    
  • utilisateurs/zarmu/systemd.1475037488.txt.gz
  • Dernière modification: Le 28/09/2016, 06:38
  • par zarmu