Le meilleur endroit pour placer les fichiers de l'unité système : /etc/systemd/system
Assurez-vous simplement d'ajouter une cible dans la section [Installer], lisez "Comment le sait-il?" pour plus de détails. UPDATE : /usr/local/lib/systemd/system
est une autre option, lisez "Zone grise" pour plus de détails. "
Le meilleur endroit pour mettre les fichiers d'unité utilisateur : /etc/systemd/user
ou $HOME/.config/systemd/user
mais cela dépend des autorisations et de la situation.
La vérité est que les unités systemd (ou, comme l'appellent les phrases d'introduction, "configurations d'unités") peuvent aller n'importe où - à condition que vous souhaitiez créer des liens symboliques manuels et que vous soyez conscient des mises en garde. Il est plus facile de placer l’appareil où vous systemctl daemon-reload
pouvez le trouver pour quelques bonnes raisons:
- L'utilisation d'un emplacement standard signifie que les générateurs systemd les trouveront et les rendront faciles à activer au démarrage
systemctl enable
. En effet, votre unité sera automatiquement ajoutée à un arbre de dépendance d'unité (un cache d'unité).
- Vous n'avez pas besoin de penser aux autorisations, car seuls les bons utilisateurs privilégiés peuvent écrire dans les zones désignées.
Comment sait-il?
Et comment savoir exactement systemctl enable
où créer le lien symbolique? Vous le codez en dur dans l'unité elle-même sous la [install]
section. Habituellement, il y a une ligne comme
[Install]
WantedBy = multi-user.target
qui correspond à un emplacement prédéfini sur le système de fichiers. De cette façon, on systemctl
sait que cette unité dépend d’un groupe de fichiers d’unités appelé multi-user.target
("cible" est le terme utilisé pour désigner les groupes de dépendance des unités. Vous pouvez lister tous les groupes avec systemctl list-units --type target
). Le groupe de fichiers unité à charger avec une cible est placé dans un targetname.target.wants
répertoire. Ceci est juste un répertoire plein de liens symboliques (ou la vraie chose). Si votre [Install]
section dit que c'est WantedBy
le multi-user.target
, mais si un lien symbolique vers celui-ci n'existe pas dans le multi-user.target.wants
répertoire, il ne se chargera pas. Lorsque les générateurs d'unité systemd ajoutent votre fichier d'unité au cache de l'arbre de dépendance au démarrage (vous pouvez déclencher manuellement les générateurs avec systemctl daemon-reload
), il sait automatiquement où placer le lien symbolique - dans ce cas, dans le répertoire./etc/systemd/system/multi-user.target.wants/
devriez-vous l'activer.
Points clés du manuel:
Des unités supplémentaires peuvent être chargées dans systemd ("lié") à partir de répertoires ne figurant pas sur le chemin de chargement de l'unité. Voir la commande de lien pour systemctl (1).
Sous systemctl, recherchez les commandes de fichier unité.
Chemin de chargement du fichier unité
Les fichiers d'unité sont chargés à partir d'un ensemble de chemins déterminé lors de la compilation, décrit dans les deux tableaux ci-dessous. Les fichiers d'unité trouvés dans les répertoires listés précédemment remplacent les fichiers portant le même nom dans les répertoires situés en bas de la liste.
Lorsque la variable $SYSTEMD_UNIT_PATH
est définie, le contenu de cette variable remplace le chemin de chargement de l'unité. Si $SYSTEMD_UNIT_PATH
se termine par un composant vide (":"), le chemin de chargement habituel des unités sera ajouté au contenu de la variable.
Les tableaux 1 et 2 man systemd.unit
sont bons.
Charger les chemins lors de l'exécution en mode système ( --system
).
/etc/systemd/system
Configuration locale
/run/systemd/system
Unités d'exécution
/usr/lib/systemd/system
Unités de paquets installés
Chemin de chargement lors de l'exécution en mode utilisateur ( --user
)
Il y a une différence entre les unités par utilisateur et toutes les unités / utilisateurs globaux .
Dépend de l'utilisateur
$XDG_CONFIG_HOME/systemd/user
Configuration utilisateur (utilisé uniquement quand $XDG_CONFIG_HOME
est défini)
$HOME/.config/systemd/user
Configuration utilisateur (utilisé uniquement lorsque $XDG_CONFIG_HOME
n'est pas défini)
$XDG_RUNTIME_DIR/systemd/user
Unités d'exécution (utilisées uniquement lorsque $XDG_RUNTIME_DIR
est défini)
$XDG_DATA_HOME/systemd/user
Unités de paquets qui ont été installées dans le répertoire de base (utilisé uniquement quand $XDG_DATA_HOME
est défini)
$HOME/.local/share/systemd/user
Unités de paquets qui ont été installées dans le répertoire de base (utilisées seulement quand $XDG_DATA_HOME
n'est pas défini)
--global
(tous les utilisateurs)
Unités qui s'appliquent à tous les utilisateurs, c'est-à-dire appartenant à chaque utilisateur. Ainsi, chaque utilisateur peut arrêter ces services même si un administrateur les active au démarrage.
/etc/systemd/user
Configuration locale pour tous les utilisateurs ( systemctl --global enable userunit.service
)
/usr/lib/systemd/user
Unités de packages installées sur l'ensemble du système pour tous les utilisateurs
/run/systemd/user
Unités d'exécution
Zone grise
D'une part, la norme de hiérarchie des fichiers spécifie qu'il /etc
s'agit de configurations locales qui n'exécutent pas les fichiers binaires. D'autre part, il est spécifié que /usr/local/
"est destiné à être utilisé par l'administrateur système lors de l'installation locale du logiciel". Vous pouvez également faire valoir (si ce n'est pas uniquement pour des raisons d'organisation) que tous les fichiers d'unité système doivent être traités /usr/local/lib/systemd/system
, mais que cela est destiné aux fichiers d'unité qui font partie d'un "logiciel" et non d'un gestionnaire de packages. Les unités utilisateur systemd correspondantes qui s’appliquent à l’échelle du système pourraient être affectées
/usr/local/lib/systemd/user
.
/etc/systemd/system
C’est là que vous mettez vos scripts, pacman y insère des scripts de paquet/usr/lib/systemd/system
et l’émissionsystemctl enable foo.service
crée des liens symboliques/usr
vers/etc
...