Activation des fichiers d'unité «liés» dans Systemd

Je suis toujours aux prises avec systemd et j'ai rencontré quelque chose. Ce n'est pas vraiment un problème, mais j'aimerais en savoir plus sur la façon dont c'est. Je n'ai pu trouver aucune référence à cela ailleurs.

Tout d'abord, je comprends que les fichiers d'unité personnalisés pour les services doivent entrer /etc/systemd/system. Cependant, ce serait bien pour la gestion de nos serveurs si les fichiers d'unité pouvaient être situés ailleurs.

Dans la documentation, j'ai vu que vous pouvez «lier» des fichiers d'unité comme ceci:

systemctl link /path/to/servicename.service

Cela créera un lien vers ce qui précède dans /etc/systemd/system. Vous pouvez maintenant démarrer / arrêter ce service. À première vue, cela semblait être un bon moyen pour nous de gérer nos services.

Cependant, essayer d'activer un tel fichier d'unité «lié» entraîne un échec:

root@test1:/etc/systemd/system# systemctl link /root/myservice.service 
Created symlink from /etc/systemd/system/myservice.service to /root/myservice.service.

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/root/myservice.service; linked; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Failed to execute operation: No such file or directory

En utilisant exactement le même fichier d'unité, mais copié dans au /etc/systemd/systemlieu d'être lié, vous obtenez:

root@test1:/etc/systemd/system# cp -p /root/myservice.service .

root@test1:/etc/systemd/system# systemctl daemon-reload 

root@test1:/etc/systemd/system# systemctl status myservice.service 
 * myservice.service - My Test Service
     Loaded: loaded (/etc/systemd/system/myservice.service; disabled; vendor preset: enabled)

root@test1:/etc/systemd/system# systemctl enable myservice.service
Created symlink from /etc/systemd/system/multi-user.target.wants/myservice.service to /etc/systemd/system/myservice.service.

De là, il semble qu'il ne soit pas possible d'activer les fichiers liés dans les unités à appeler au démarrage du système.

Si tel est le cas, quel est l'intérêt de la fonctionnalité «lien»? D'après les documents, il dit:

lien FILENAME

Liez un fichier d'unité qui ne se trouve pas dans les chemins de recherche de fichier d'unité dans le chemin de recherche de fichier d'unité. Cela nécessite un chemin absolu vers un fichier d'unité. L'effet de cela peut être annulé avec désactiver. L'effet de cette commande est qu'un fichier d'unité est disponible pour le démarrage et d'autres commandes bien qu'il ne soit pas installé directement dans le chemin de recherche d'unité.

La page de manuel est trompeuse.

systemctl link /root/myservice.service

systemctl enable /root/myservice.service

Le premier vous permet de le faire systemctl start myservice. La seconde permet myservicede démarrer automatiquement (ce qui, comme l'a souligné @Julien, ajoute automatiquement le link).

Je pense ... J'ai essayé d'envelopper ma tête toute la journée.

Lorsque vous activez un service à partir d'un autre chemin que les chemins par défaut, vous devez utiliser le chemin complet. Activer créera également le lien pour vous:

systemctl enable /root/myservice.service

Une fois activé, vous pouvez démarrer / arrêter / statut avec le nom du service

systemctl start myservice

Quelques mises en garde ici:

• vous ne pouvez pas activer un fichier de service qui est déjà en lui-même un lien
• assurez-vous que le chemin se trouve sur le même disque monté. Si ce n'est pas le cas, systemd ne pourra pas charger les fichiers de l'unité de service au démarrage car le disque ne sera pas encore monté et les fichiers ne seront pas trouvés. (voir Échec du chargement des fichiers d'unité liés Systemd sur le disque monté )
• en raison d'un bogue dans systemd, vous ne pouvez pas activer les instances à partir d'un fichier d'unité qui se trouve dans un chemin non standard (voir https://github.com/systemd/systemd/issues/661 )