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édentesRévision précédente
Prochaine révision		Révision précédente
utilisateurs:zarmu:systemd [Le 28/09/2016, 06:38] – [Personnaliser un fichier de configuration Systemd] zarmuutilisateurs:zarmu:systemd [Le 11/09/2022, 13:14] (Version actuelle) – 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) moths-art
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 =====
    
utilisateurs/zarmu/systemd.1475037488.txt.gz · Dernière modification : de zarmu
CC Attribution-Noncommercial-Share Alike 4.0 International Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC Attribution-Noncommercial-Share Alike 4.0 International