9.6. Créer et modifier des fichiers d'unité systemd
systemctl
fonctionnent avec des fichiers d'unité dans l'arrière-plan. Pour faire des ajustements plus précis, l'administrateur systèmes doit modifier ou créer des fichiers d'unité manuellement. La Tableau 9.2, « Emplacements des fichiers d'unités systemd » répertorie trois répertoires principaux sur lesquels les fichiers d'unités sont stockés sur le système, le répertoire /etc/systemd/system/
est réservé aux fichiers d'unité créés ou personnalisés par l'administrateur systèmes.
unit_name.type_extension
sshd.service
et une unité sshd.socket
sont habituellement présentes sur votre système.
sshd.service
, veuillez créer le fichier sshd.service.d/custom.conf
et insérez-y les directives supplémentaires. Pour obtenir davantage d'informations sur les répertoires de configuration, veuillez consulter la Section 9.6.4, « Modifier les fichiers d'unité existants ».
sshd.service.wants/
et sshd.service.requires/
peuvent également être créés. Ces répertoires contiennent des liens symboliques vers les fichiers d'unités qui sont des dépendances du service sshd
. Les liens symboliques sont automatiquement créés pendant l'installation selon les options du fichiers de l'unité [Install] (veuillez consulter la Tableau 9.11, « Options importantes de la section [Install] ») ou pendant le temps d'exécution basé sur les options [Unit] (veuillez consulter la Tableau 9.9, « Options importantes de la section [Unit] »). Il est également possible de créer ces répertoires et les liens symboliques manuellement.
9.6.1. Comprendre la structure des fichiers d'unité
- [Unit] — contient des options génériques qui ne sont pas dépendantes du type de l'unité. Ces options fournissent une description de l'unité, spécifient le comportement de l'unité, et définissent les dépendances avec d'autres unités. Pour une liste des options [Unit] les plus fréquemment utilisées, veuillez consulter la Tableau 9.9, « Options importantes de la section [Unit] ».
- [unit type] — si une unité possède des directives spécifiques au type, celles-ci seront regroupées dans une section nommée par le type d'unité. Par exemple, les fichiers de l'unité de service contiennent la section [Service], veuillez consulter la Tableau 9.10, « Options importantes de la section [Service] » pour voir les options [Service] les plus fréquemment utilisées.
- [Install] — contient des informations sur l'installation de l'unité utilisée par les commandes
systemctl enable
etdisable
, veuillez consulter la Tableau 9.11, « Options importantes de la section [Install] » pour voir une liste des options [Install].
Option[a] | Description |
---|---|
Description | Description significative de l'unité. En tant qu'exemple, le texte est affiché dans la sortie de la commande systemctl status . |
Documentation | Fournit une liste des URI référençant la documentation de l'unité. |
After [b] | Définit l'ordre dans lequel les unités sont lancées. L'unité est lancée uniquement après l'activation des unités spécifiées dans After . Contrairement à Requires , After n'active pas explicitement les unités spécifiées. L'option Before offre une fonctionnalité contraire à After . |
Requires | Configure les dépendances sur d'autres unités. Les unités répertoriées dans Requires sont activées ensembles avec l'unité. Si le lancement de l'une des unités requises échoue, l'unité n'est pas activée. |
Wants | Configure les dépendances plus faibles que Requires . Si l'une des unités répertoriées ne démarre pas, cela n'aura pas d'impact sur l'activation de l'unité. C'est la méthode recommandée pour établir des dépendances d'unité personnalisées. |
Conflicts | Configure des dépendances négatives, à l'opposé de Requires . |
[a]
Pour une liste complète des options configurables dans la section [Unit], veuillez consulter la page man de systemd.unit(5) .
[b]
Dans la plupart des cas, il est suffisant de ne déterminer que les dépendances d'ordonnancement qu'avec les options de fichier After et Before . Si vous définissez aussi une dépendance avec Wants (conseillé) ou Requires , la dépendance d'ordonnancement devra toujours être spécifiée. C'est parce que l'ordonnancement et les exigences de dépendances fonctionnent indépendamment.
|
Option[a] | Description |
---|---|
Type | Configure le type de démarrage de processus d'unité qui affecte la fonctionnalité d'ExecStart et des options connexes. L'une des options suivantes :
|
ExecStart | Spécifie les commandes ou scripts à exécuter lorsque l'unité est lancée. ExecStartPre et ExecStartPost spécifient des commandes personnalisées à exécuter avant et après ExecStart . Type=oneshot permet de spécifier des commandes multiples personnalisées exécutées de manière séquentielle par la suite. |
ExecStop | Spécifie les commandes ou scripts à exécuter lorsque l'unité est arrêtée. |
ExecReload | Spécifie les commandes ou scripts à exécuter lorsque l'unité est rechargée. |
Restart | Avec cette option activée, le service est redémarré après que son processus se soit arrêté, à l'exception d'un arrêt gracieux avec la commande systemctl . |
RemainAfterExit | Si défini sur True, le service est considéré comme actif, même lorsque tous ses processus sont arrêtés. La valeur par défaut est False. Cette option est particulièrement utile si Type=oneshot est configuré. |
[a]
Pour une liste complète des options configurables dans la section [Service], veuillez consulter la page man de systemd.service(5) .
|
Option[a] | Description |
---|---|
Alias | Fournit une liste de noms supplémentaires de l'unité séparés par des espaces. La plupart des commandes systemctl , sauf systemctl enable , peuvent utiliser des alias à la place du nom de l'unité. |
RequiredBy | Une liste des unités qui dépendent de l'unité. Lorsque cette unité est activée, les unités répertoriées dans RequiredBy obtiennent une dépendance Require de l'unité. |
WantedBy | Une liste des unités qui dépendent faiblement de l'unité. Lorsque cette unité est activée, les unités répertoriées dans WantedBy obtiennent une dépendance Want de l'unité. |
Also | Indique une liste des unités à installer ou désinstaller avec l'unité. |
DefaultInstance | Limitée aux unités instanciées, cette option indique l'instance par défaut pour laquelle l'unité est activée. Veuillez consulter la Section 9.6.5, « Travailler avec des unités instanciées » |
[a]
Pour voir une liste complète des options configurables dans la section [Install], veuillez consulter la page man de systemd.unit(5) .
|
Exemple 9.17. Fichier d'unité postfix.service
/usr/lib/systemd/system/postifix.service
tel qu'il est fourni par le paquet postfix :
[Unit] Description=Postfix Mail Transport Agent After=syslog.target network.target Conflicts=sendmail.service exim.service [Service] Type=forking PIDFile=/var/spool/postfix/pid/master.pid EnvironmentFile=-/etc/sysconfig/network ExecStartPre=-/usr/libexec/postfix/aliasesdb ExecStartPre=-/usr/libexec/postfix/chroot-update ExecStart=/usr/sbin/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop [Install] WantedBy=multi-user.target
EnvironmentFile
désigne l'emplacement où les variables d'environnement du service sont définies, PIDFile
spécifie un PID stable pour le processus principale du service. Finalement, la section [Install] répertorie les unités qui dépendent de ce service.
9.6.2. Créer des fichiers d'unité personnalisés
- Préparez le fichier exécutable avec le service personnalisé. Il peut s'agir d'un script créé et personnalisé, ou d'un exécutable remis par un fournisseur de logiciels. Si requis, veuillez préparer un fichier PID pour contenir un PID constant pour le processus principal du service personnalisé. Il est également possible d'inclure des fichiers d'environnement pour stocker des variables shell pour le service. Assurez-vous que le script source soit exécutable (en exécutant
chmod a+x
) et qu'il ne soit pas interactif. - Créez un fichier d'unité dans le répertoire
/etc/systemd/system/
et assurez-vous qu'il possède les permissions de fichier correctes. Veuillez exécuter en tant qu'utilisateurroot
:touch
/etc/systemd/system/name.service
chmod 664
/etc/systemd/system/name.service
Remplacez name par le nom du service à créer. Remarquez que le fichier n'a pas besoin d'être exécutable. - Ouvrez le fichier
name.service
créé dans l'étape précédente, et ajoutez les options de configuration du service. Une variété d'options peut être utilisée selon le type de service que vous souhaitez créer, consulter Section 9.6.1, « Comprendre la structure des fichiers d'unité ». Voici un exemple de configuration d'unité pour un service concernant le réseau :[Unit] Description=service_description After=network.target [Service] ExecStart=path_to_executable Type=forking PIDFile=path_to_pidfile [Install] WantedBy=default.target
Quand :- service_description est une description informative affichée dans les fichiers journaux et dans la sortie de la commande
systemctl status
. - le paramètre
After
permet de s'assurer que le service est démarré uniquement après l'exécution du réseau. Ajoutez une liste séparée par des espaces d'autres services ou cibles connexes. - path_to_executable correspond au chemin vers l'exécutable du service.
Type=forking
est utilisé pour les démons effectuant l'appel système « fork ». Le processus principal du service est créé avec le PID spécifié dans path_to_pidfile. D'autres types de démarrage se trouvent dans la Tableau 9.10, « Options importantes de la section [Service] ».WantedBy
fait état de la cible ou des cibles sous laquelle ou sous lesquelles le service devrait être lancé. Ces cibles peuvent être vues comme remplaçant l'ancien concept des niveaux d'exécution, veuillez consulter la Section 9.3, « Travailler avec des cibles Systemd » pour obtenir des détails supplémentaires.
- Notifier systemd qu'un nouveau fichier
name.service
existe en exécutant la commande suivante en tant qu'utilisateurroot
:systemctl
daemon-reload
systemctl start name.service
Avertissement
Exécutez la commandesystemctl daemon-reload
à chaque fois que vous créez des nouveaux fichiers d'unités ou lorsque vous modifiez des fichiers d'unités existants. Sinon, les commandessystemctl start
ousystemctl enable
peuvent échouer à cause d'une mauvaise correspondance entre les états de systemd et les fichiers d'unités de service qui se trouvent sur le disque.L'unité name.service peut désormais être gérée comme tout autre service système par des commandes décrites dans la Section 9.2, « Gérer les services système ».
Exemple 9.18. Créer le fichier emacs.service
- Créez un fichier d'unité dans le répertoire
/etc/systemd/system/
et assurez-vous qu'il possède les permissions de fichier correctes. Veuillez exécuter en tant qu'utilisateurroot
:~]#
touch
~]#/etc/systemd/system/emacs.service
chmod 664
/etc/systemd/system/emacs.service
- Ajouter le contenu suivant au fichier de configuration :
[Unit] Description=Emacs: the extensible, self-documenting text editor [Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" Environment=SSH_AUTH_SOCK=%t/keyring/ssh Restart=always [Install] WantedBy=default.target
Avec la configuration ci-dessus, l'exécutable/usr/bin/emacs
est lancé en mode démon pendant le démarrage du service. La variable d'environnement SSH_AUTH_SOCK est paramétrée en utilisant le spécificateur d'unité « %t » qui correspond au répertoire du runtime. Le service redémarre également le processus Emacs s'il s'arrête de manière inattendue. - Veuillez exécuter les commandes suivantes pour recharger la configuration et lancer le service personnalisé :
~]#
systemctl
~]#daemon-reload
systemctl start emacs.service
systemctl
standard. Ainsi, exécutez systemctl status emacs
pour afficher le statut de l'éditeur ou systemctl enable emacs
pour le lancer automatiquement pendant le démarrage système.
Exemple 9.19. Création d'une seconde instance du service sshd
sshd
:
- Veuillez créer une copie du fichier
sshd_config
qui sera utilisée par le second démon :~]#
cp /etc/ssh/sshd{,-second}_config
- Veuillez modifier le fichier
sshd-second_config
créé dans l'étape précédente pour assigner un numéro de port différent et un fichier PID au second démon :Port 22220 PidFile /var/run/sshd-second.pid
Veuillez consulter la page man desshd_config
(5) pour obtenir plus d'informations sur les optionsPort
etPidFile
. Assurez-vous que le port choisi n'est pas en cours d'utilisation par un autre service. Le fichier PID ne doit pas forcément exister avant l'exécution du service, il est généré automatiquement lors du démarrage du service. - Veuillez créer une copie du fichier d'unité systemd pour le service
sshd
.~]#
cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
- Veuillez altérer le fichier
sshd-second.service
créé pendant l'étape précédente comme suit:- Modifiez l'option
Description
:Description=OpenSSH server second instance daemon
- Veuillez ajouter sshd.service aux services spécifiés dans l'option
After
, afin que la seconde instance soit lancée uniquement après le lancement de la première :After=syslog.target network.target auditd.service sshd.service
- La première instance de sshd inclut la génération de clés, veuillez donc supprimer la ligne ExecStartPre=/usr/sbin/sshd-keygen.
- Ajoutez le paramètre
-f /etc/ssh/sshd-second_config
à la commandesshd
afin que le fichier de configuration alternatif soit utilisé :ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
- Après les modifications indiquées ci-dessus, le fichier sshd-second.service devrait ressembler à ce qui suit :
[Unit] Description=OpenSSH server second instance daemon After=syslog.target network.target auditd.service sshd.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
- Si vous utilisez SELinux, veuillez ajouter le port pour la seconde instance de sshd sur les ports SSH, sinon la seconde instance de sshd sera rejetée pour lier le port :
~]#
semanage port -a -t ssh_port_t -p tcp 22220
- Veuillez activer sshd-second.service, afin qu'il soit lancé automatiquement pendant le démarrage :
~]#
systemctl enable sshd-second.service
Vérifiez si sshd-second.service est en cours d'utilisation par la commandesystemctl status
. Veuillez également vérifier si le port est activé correctement en effectuant une connexion au service :~]$
ssh -p 22220 user@server
Si le pare-feu est en cours d'utilisation, veuillez vous assurer qu'il soit correctement configuré de manière à permettre des connexions à la seconde instance de sshd.
9.6.3. Convertir des scripts init SysV en fichiers d'unité
postfix
sur Red Hat Enterprise Linux 6 :
#!/bin/bash # # postfix Postfix Mail Transfer Agent # # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program \ # that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf ### BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that # moves mail from one machine to another. ### END INIT INFO
Trouver la description du service
Description
de la section [Unit] du fichier d'unité. L'en-tête LSB peut contenir des données similaires sur les lignes #Short-Description et #Description.
Trouver les dépendances de service
Option LSB | Description | Équivalent de fichier d'unité |
---|---|---|
Provides | Spécifie le nom de l'installation de démarrage du service, à qui il peut être fait référence dans d'autres scripts init (avec le préfixe « $ »). Ceci n'est plus nécessaire car les fichiers d'unité font référence aux autres unités par leur nom de fichier. | – |
Required-Start | Contient les noms des installations de démarrage des services requis. Ceci se traduit par une dépendance d'ordre, les noms d'installations de démarrage sont remplacés par les noms des fichiers d'unité des services correspondants ou les cibles auxquelles ils appartiennent. Par exemple, dans le cas de postfix , la dépendance « Required-Start » sur « $network » a été traduite sur la dépendance « After » sur « network.target ». | After , Before |
Should-Start | Constitue des dépendances plus faibles que Required-Start. Les dépendances Should-Start échouées n'affecteront pas le démarrage du service. | After , Before |
Required-Stop , Should-Stop | Constitue des dépendances négatives. | Conflicts |
Trouver les cibles par défaut du service
WantedBy
de la section [Install] du fichier d'unité. Par exemple, postfix
avait auparavant été lancé dans les niveaux d'exécution 2, 3, 4, et 5, qui se traduisent par multi-user.target et graphical.target dans Red Hat Enterprise Linux 7. Veuillez remarquer que graphical.target dépend de multiuser.target, donc il n'est pas nécessaire de spécifier les deux, comme dans l'Exemple 9.17, « Fichier d'unité postfix.service ». Vous trouverez également des informations sur les niveaux d'exécution par défaut et interdits dans les lignes #Default-Start et #Default-Stop de l'en-tête LSB.
Trouver les fichiers utilisés par le service
EnvironmentFile
. Le fichier PID spécifié sur la ligne du script init #pidfile est importé sur le fichier d'unité avec l'option PIDFile
.
postfix
affiche le bloc de code à exécuter lors du lancement du service.
conf_check() { [ -x /usr/sbin/postfix ] || exit 5 [ -d /etc/postfix ] || exit 6 [ -d /var/spool/postfix ] || exit 5 } make_aliasesdb() { if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ] then # /etc/aliases.db might be used by other MTA, make sure nothing # has touched it since our last newaliases call [ /etc/aliases -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] || [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return /usr/bin/newaliases touch -r /etc/aliases.db "$ALIASESDB_STAMP" else /usr/bin/newaliases fi } start() { [ "$EUID" != "0" ] && exit 4 # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 conf_check # Start daemons. echo -n $"Starting postfix: " make_aliasesdb >/dev/null 2>&1 [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start" RETVAL=$? [ $RETVAL -eq 0 ] && touch $lockfile echo return $RETVAL }
conf_check()
et make_aliasesdb()
, qui sont appelées à partir du bloc de la fonction start()
. En examinant cela de plus près, plusieurs fichiers externes et plusieurs répertoires sont mentionnés dans le code ci-dessus : l'exécutable du service principal, /usr/sbin/postfix
, les répertoires de configuration/etc/postfix/
et /var/spool/postfix/
, ainsi que le répertoire /usr/sbin/postconf/
.
ExecStart
, ExecStartPre
, ExecStartPost
, ExecStop
, et ExecReload
. Dans le cas de postfix
dans Red Hat Enterprise Linux 7, /usr/sbin/postfix
accompagné de scripts pris en charge sont exécutés pendant le lancement du service. Veuillez consulter le fichier d'unité postfix
dans l'Exemple 9.17, « Fichier d'unité postfix.service ».
9.6.4. Modifier les fichiers d'unité existants
/usr/lib/systemd/system/
. Les administrateurs systèmes ne doivent pas modifier ces fichiers directement, ainsi toute personnalisation doit être confinée aux fichiers de configuration dans le répertoire /etc/systemd/system/
. Veuillez choisir l'une des approches suivantes, en fonction de l'étendue des changements requis :
- Veuillez créer un répertoire pour les fichiers de configuration supplémentaires dans
/etc/systemd/system/unit.d/
. Cette méthode est recommandée pour la plupart des cas d'utilisation. Elle permet d'étendre la configuration par défaut avec des fonctionnalités supplémentaires, tout en continuant à faire référence au fichier d'unité d'origine. Les changements apportés à l'unité par défaut qui ont eu lieu lors d'une mise à niveau de paquet(s) sont ainsi appliqués automatiquement. Veuillez consulter la section intitulée « Étendre la configuration de l'unité par défaut » pour obtenir davantage d'informations. - Veuillez créer une copie du fichier d'unité d'origine
/usr/lib/systemd/system/
dans/etc/systemd/system/
et effectuez-y les changements souhaités. La copie remplace le fichier d'origine, donc les changement introduits par la mise à jour du paquet ne sont pas appliqués. Cette méthode est utile pour effectuer des changements significatifs qui devront être persistants, quelles que soient les mises à jour de paquets se produisant. Veuillez consulter la section intitulée « Remplacer la configuration de l'unité par défaut » pour obtenir des détails.
/etc/systemd/system/
. Pour appliquer les changements aux fichiers d'unité sans redémarrer le système, veuillez exécuter :
systemctl daemon-reload
daemon-reload
recharge tous les fichiers d'unité et recrée la totalité de l'arbre de dépendances, ce qui est nécessaire pour appliquer immédiatement tout changement sur un fichier d'unité. Alternativement, le même résultat peut être atteint à l'aide de la commande suivante :
init q
systemctl restart name.service
Étendre la configuration de l'unité par défaut
/etc/systemd/system/
. Si vous étendez une unité de service, veuillez exécuter la commande suivante en tant qu'utilisateur root
:
mkdir /etc/systemd/system/name.service.d/
touch /etc/systemd/system/name.service.d/config_name.conf
[Unit] Requires=new_dependency After=new_dependency
[Service] Restart=always RestartSec=30
root
:
systemctl
daemon-reload
systemctl restart name.service
Exemple 9.20. Étendre la configuration httpd.service
~]#mkdir
~]#/etc/systemd/system/httpd.service.d/
touch
/etc/systemd/system/httpd.service.d/custom_script.conf
/usr/local/bin/custom.sh
, veuillez insérer le texte suivant dans le fichier custom_script.conf
:
[Service] ExecStartPost=/usr/local/bin/custom.sh
~]#systemctl
~]#daemon-reload
systemctl restart httpd.service
Note
/etc/systemd/system/
ont priorité sur les fichiers d'unité dans /usr/lib/systemd/system/
. Ainsi, si les fichiers de configuration contiennent une option qui peut être spécifiée une seule fois, comme Description
ou ExecStart
, la valeur par défaut de cette option sera remplacée. Remarquez que dans la sortie de la commande systemd-delta
décrite dans la section intitulée « Surveiller les unités remplacées », de telles unités sont toujours marquées comme [EXTENDED], même si au total, certaines options sont remplacées.
Remplacer la configuration de l'unité par défaut
/etc/systemd/system/
. Pour cela, veuillez exécuter la commande suivante en tant qu'utilisateur root
:
cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service
root
:
systemctl
daemon-reload
systemctl restart name.service
Exemple 9.21. Modifier la limite du délai d'attente
/etc/systemd/system/network.service.d/timeout.conf
et ajouter une ligne à la nouvelle configuration à ce endroit. La commande systemctl show network -p TimeoutStartUSec
affichera le délai d’attente actuel maximum. Après avoir changé la limite à 10 secondes, comme dans l’exemple ci-dessous, pensez à redémarrer systemd
avec systemctl daemon-reload pour que les modifications puissent entrer en vigueur :
~]#systemctl show network -p TimeoutStartUSec
TimeoutStartUSec=5min ~]#mkdir /etc/systemd/system/network.service.d/
~]#echo -e '[Service]\nTimeoutStartSec=10' > /etc/systemd/system/network.service.d/timeout.conf
~]#systemctl daemon-reload
~]#systemctl show network -p TimeoutStartUSec
TimeoutStartUSec=10s
Surveiller les unités remplacées
systemd-delta
[EQUIVALENT] /etc/systemd/system/default.target/usr/lib/systemd/system/default.target [OVERRIDDEN] /etc/systemd/system/autofs.service /usr/lib/systemd/system/autofs.service --- /usr/lib/systemd/system/autofs.service 2014-10-16 21:30:39.000000000 -0400 +++ /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500 @@ -8,7 +8,8 @@ EnvironmentFile=-/etc/sysconfig/autofs ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid ExecReload=/usr/bin/kill -HUP $MAINPID -TimeoutSec=180 +TimeoutSec=240 +Restart=Always [Install] WantedBy=multi-user.target [MASKED] /etc/systemd/system/cups.service /usr/lib/systemd/system/cups.service [EXTENDED] /usr/lib/systemd/system/sssd.service /etc/systemd/system/sssd.service.d/journal.conf 4 overridden configuration files found.
systemd-delta
. Remarquez que si un fichier est remplacé, systemd-delta
affiche par défaut un sommaire des changements similaires à la sortie de la commande diff
.
Type | Description |
---|---|
[MASKED]
|
Fichiers d'unités masqués, veuillez consulter la Section 9.2.7, « Désactiver un service » pour une description du masquage d'unité.
|
[EQUIVALENT]
|
Copies non modifiées qui remplacent les fichiers d'origine mais dont le contenu, typiquement les liens symboliques, ne diffère pas.
|
[REDIRECTED]
|
Fichiers redirigés vers d'autres fichiers.
|
[OVERRIDEN]
|
Fichiers remplacés et modifiés.
|
[EXTENDED]
|
Fichiers étendus avec les fichiers .conf dans le répertoire
/etc/systemd/system/unit.d/ .
|
[UNCHANGED]
|
Fichiers non modifiés, uniquement affichés lorsque l'option
--type=unchanged est utilisée.
|
systemd-delta
après une mise à jour système pour vérifier si des mises à jour d'unités par défaut sont actuellement remplacées par une configuration personnalisée. Il est également possible de limiter la sortie à un certain type de différence uniquement. Par exemple, pour uniquement afficher les unités remplacées, veuillez exécuter :
systemd-delta --type=overridden
9.6.5. Travailler avec des unités instanciées
Requires
ou Wants
), ou par la commande systemctl start
. Les unités de service instanciées sont nommées comme suit.
template_name@instance_name.service
unit_name@.service
Wants
suivant dans un fichier d'unité :
Wants=getty@ttyA.service,getty@ttyB.service
getty@.service
, lira la configuration à partir de celui-ci, et lancera les services.
Spécificateur d'unité | Signification | Description |
---|---|---|
%n | Nom d'unité complet | Correspond au nom d'unité complet, y compris le suffixe du type. %N possède la même signification mais remplace également les caractères interdits avec les codes ASCII. |
%p | Nom du préfixe | Correspond à un nom d'unité avec le suffixe de type supprimé. Pour les unités instanciées, %p correspond à la partie du nom de l'unité avant le caractère « @ ». |
%i | Nom d'instance | Il s'agit de la partie du nom d'unité instanciée entre le caractère « @ » et le suffixe du type. %I possède la même signification mais remplace également les caractères interdits par des codes ASCII. |
%H | Nom d'hôte | Correspond au nom d'hôte du système en cours d'exécution au moment où la configuration de l'unité est chargée. |
%t | Répertoire du runtime | Représente le répertoire du runtime, qui est /run pour l'utilisateur root , ou la valeur de la variable XDG_RUNTIME_DIR pour les utilisateur non-privilégiés. |
systemd.unit(5)
.
getty@.service
contient les directives suivante :
[Unit] Description=Getty on %I ... [Service] ExecStart=-/sbin/agetty --noclear %I $TERM ...
Description
= est résolu en tant que Getty on ttyA et Getty on ttyB.