J'ai lu qu'il y avait deux dossiers pour les fichiers unitaires (pas en mode utilisateur).

/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator

En conflit avec cette compréhension est la réponse à cette question :Comment écrire un script de démarrage pour Systemd. Quelqu'un peut-il compléter les informations manquantes afin que je comprenne ce qui se passe ? (MISE À JOUR :La réponse a été mise à jour et ma compréhension n'est plus en conflit avec elle. )

De plus, il semble que les scripts soient organisés en sous-dossiers dans /etc/systemd/system/ dossier :

getty.target.wants
multi-user.target.wants

Dans un autre endroit, j'ai lu qu'il y avait d'autres endroits. Il semble que ce soient des services spécifiques à l'utilisateur.

/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.

Mise à jour 2015-08-31 :

Pour le bien des autres, voici un lien vers une question connexe que j'ai récemment posée :où placer les scripts exécutés par les unités systemd ?

Réponse acceptée :

Le meilleur endroit pour mettre le système fichiers unitaires : /etc/systemd/system Assurez-vous simplement d'ajouter une cible dans la section [Installer], lisez "Comment le sait-il?" pour plus de détails. MISE À JOUR :/usr/local/lib/systemd/system est une autre option, lisez "Zone grise" pour plus de détails."

Le meilleur endroit pour mettre utilisateur fichiers unitaires : /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 les appelle la phrase d'introduction, les "configurations d'unités") peuvent aller n'importe où - à condition que vous soyez prêt à créer des liens symboliques manuels et que vous soyez conscient des mises en garde. Cela facilite la vie de mettre l'unité où systemctl daemon-reload peut le trouver pour de 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 avec 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 le sait-il ?

Et comment exactement systemctl enable savez où créer le lien symbolique? Vous le codez en dur dans l'unité
elle-même sous le [install] section. Habituellement, il y a une ligne comme

[Install]
WantedBy = multi-user.target

qui correspond à un endroit prédéfini sur le système de fichiers.
De cette façon, systemctl sait que cette unité dépend d'un groupe de fichiers d'unité appelé multi-user.target ("cible" est le terme utilisé pour désigner les groupes de dépendance d'unité. Vous pouvez lister tous les groupes avec systemctl list-units --type target ). Le groupe de fichiers unitaires à charger avec une cible est placé dans un targetname.target.wants annuaire. Ceci est juste un répertoire plein de liens symboliques (ou la vraie chose). Si votre [Install] la section indique qu'il s'agit de 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és systemd ajoutent votre fichier d'unité au cache de l'arborescence des dépendances 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ées") à partir de
répertoires ne se trouvant pas sur le chemin de chargement de l'unité. Voir la commande de lien pour
systemctl(1).

Sous systemctl, recherchez Unit File Commands

Chemin de chargement du fichier d'unité

Veuillez lire et comprendre la première phrase de la citation suivante de man systemd.unit (car cela implique que tous les chemins que je mentionne ici peuvent ne pas s'appliquer à vous si votre systemd a été compilé avec des chemins différents) :

Les fichiers unitaires sont chargés à partir d'un ensemble de chemins déterminés lors de la compilation, décrits dans les deux tableaux ci-dessous. Les fichiers d'unité trouvés dans les répertoires répertoriés précédemment remplacent les fichiers portant le même nom dans les répertoires inférieurs dans la liste.

Lorsque la variable $SYSTEMD_UNIT_PATH est défini, le contenu de cette variable remplace le chemin de charge unitaire. Si $SYSTEMD_UNIT_PATH se termine par un composant vide (":"), le chemin de charge unitaire habituel sera ajouté au contenu de la variable.

Tableau 1 et Tableau 2 de man systemd.unit sont bons.

Connexe :l'écho vers le descripteur de fichier écrase le fichier ?

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 des packages installés (ou /lib/systemd/system dans certains cas, lisez man systemd.unit )

Charger le chemin lors de l'exécution en mode utilisateur (--user )

Il y a une différence entre par utilisateur unités et tous/global unités utilisateurs.

Dépend de l'utilisateur

• $XDG_CONFIG_HOME/systemd/user Configuration utilisateur (utilisée uniquement lorsque $XDG_CONFIG_HOME est défini)

• $HOME/.config/systemd/user Configuration utilisateur (utilisée 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 packages qui ont été installés dans le répertoire personnel (utilisés uniquement lorsque $XDG_DATA_HOME est défini)

• $HOME/.local/share/systemd/user Unités de packages qui ont été installés dans le répertoire personnel (utilisés uniquement lorsque $XDG_DATA_HOME n'est pas défini)

--global (tous les utilisateurs)

Unités qui s'appliquent à tous les utilisateurs, c'est-à-dire détenues par chaque utilisateur également. 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 qui ont été installés à l'échelle du système pour tous les utilisateurs (ou /lib/systemd/system dans certains cas, lisez man systemd.unit)
• /run/systemd/user Unités d'exécution

Zone grise

D'une part, le File Hierarchy Standard spécifie que /etc est pour les configurations locales qui n'exécutent pas les binaires. Par contre
il précise 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 uniquement à des fins d'organisation) que tous les fichiers de l'unité système doivent être placés sous /usr/local/lib/systemd/system , mais cela est destiné aux fichiers d'unité qui font partie du "logiciel" et non d'un gestionnaire de packages.
Les unités utilisateur systemd correspondantes qui sont à l'échelle du système peuvent aller sous /usr/local/lib/systemd/user .

Unité transitoire

Un autre endroit oublié n'est nulle part du tout! Peut-être qu'un programme moins connu est systemd-run . Vous pouvez l'utiliser pour exécuter des unités transitoires à la volée. voir man systemd-run .

Par exemple, pour programmer un redémarrage demain matin à 4 h 00 (vous aurez peut-être besoin de --force pour s'assurer qu'un redémarrage a lieu) :

systemd-run -u restart --description="Restarts machine" --on-calendar="2020-12-18 00:04:00" systemctl --force reboot

Cela donnera un fichier d'unité transitoire restart.service et une minuterie correspondante (à cause du --on-calendar , indiqué par transient=yes .

/run/systemd/transient/restart.service

# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=Restarts machine

[Service]
ExecStart=
ExecStart="/usr/bin/systemctl" "--force" "reboot"

Notez qu'il existe également l'option de double force plus dangereuse --force --force , qui indique au noyau de s'arrêter immédiatement (et, si vous ne savez pas ce que vous faites, de manière dangereuse, car cela équivaut presque à couper l'alimentation).

Connexe :Dispositif à faible consommation d'énergie dans une unité scellée - aide à la conception ?