J'ai lu qu'il y a deux dossiers pour les fichiers d'unité (pas en mode utilisateur).

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

La réponse suivante est en conflit avec cette interprétation: https://unix.stackexchange.com/a/47715/33386 . Quelqu'un peut-il compléter les informations manquantes pour que je comprenne ce qui se passe? ( UPDATE: 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 le /etc/systemd/system/dossier:

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

Dans un autre endroit, j'ai lu qu'il y en avait d'autres. Il semble que ce sont 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 l’intérêt des autres, voici un lien vers une question connexe que j’avais récemment posée: où placer les scripts exécutés par des unités systemd?

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/systemest 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-reloadpouvez 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 enableoù 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 systemctlsait 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.wantsrépertoire. Ceci est juste un répertoire plein de liens symboliques (ou la vraie chose). Si votre [Install]section dit que c'est WantedByle multi-user.target, mais si un lien symbolique vers celui-ci n'existe pas dans le multi-user.target.wantsré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_PATHest définie, le contenu de cette variable remplace le chemin de chargement de l'unité. Si $SYSTEMD_UNIT_PATHse 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.unitsont 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_HOMEest défini)
• $HOME/.config/systemd/user Configuration utilisateur (utilisé uniquement lorsque $XDG_CONFIG_HOMEn'est pas défini)

• $XDG_RUNTIME_DIR/systemd/user Unités d'exécution (utilisées uniquement lorsque $XDG_RUNTIME_DIRest 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_HOMEest 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_HOMEn'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 /etcs'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/systemest l' endroit où vous mettez vos scripts, pacman puts package scripts dans /usr/lib/systemd/system.

L'émission systemctl enable foo.servicecrée des liens symboliques de /usrà /etc. Voir la section Chemin de chargement des unités man systemd.unit(5)pour plus de détails.

J'ai écrit 3, un pour ntpd, un pour un deuxième, carte Ethernet statique, et un pour exécuter p0f, l'identificateur passif du système d'exploitation. Je les ai tous mis dedans /etc/systemd/system. On dirait que je pourrais peut-être laisser systemdle soin de gérer les affaires NTP, mais je ne pense pas que je veuille vraiment compter dessus.