Activation des files unitaires 'liés' dans Systemd

Je suis encore aux sockets 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 il s'agit. Je n'ai trouvé aucune reference à cela ailleurs.

Tout d'abord, je comprends que les files unitaires personnalisés pour les services devraient aller dans /etc/systemd/system . Cependant, ce serait bien pour la gestion de nos servers si les files de l'unité pouvaient être localisés ailleurs.

Dans la documentation, j'ai vu que vous pouvez 'lier' des files unitaires comme ceci:

 systemctl link /path/to/servicename.service

Cela créera un lien vers le file ci-dessus dans /etc/systemd/system . Vous êtes maintenant en mesure de démarrer / arrêter ce service. En surface, cela semblait être une bonne façon pour nous de gérer nos services.

Cependant, essayer d'activer un file 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 file d'unité, mais copié dans /etc/systemd/system au lieu 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.

À partir de cela, il semble qu'il ne soit pas possible d'activer l'association des files unitaires au démarrage du système.

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

lien FILENAME

Lier un file d'unité qui ne figure pas dans les paths de search du file unité dans le path de search du file unité. Cela nécessite un path absolu vers un file d'unité. L'effet de ceci peut être annulé avec désactivation. L'effet de cette command est qu'un file d'unité est disponible pour les commands de démarrage et d'autres, bien qu'il ne soit pas installé directement dans le path de search de l'unité.

La page de manuel est trompeuse.

~~systemctl link /root/myservice.service~~

 systemctl enable /root/myservice.service

Le premier vous permet de faire systemctl start myservice . Le second permet de lancer automatiquement myservice (qui, comme @Julien l'a souligné, ajoute automatiquement le link ).

Je pense … J'ai essayé de m'envelopper toute la journée.

Lorsque vous activez un service à partir d'un autre path que les paths par défaut, vous devez utiliser le path 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 file de service qui est déjà en lui-même un lien
assurez-vous que le path est sur le même disque monté. Si ce n'est pas le cas, systemd ne pourra pas charger les files de l'unité de service au démarrage car le disque ne sera pas encore monté et les files ne seront pas trouvés. (voir les files d'unités liées au système sur le disque monté ne parviennent pas à se charger )
en raison d'un bug dans systemd, vous ne pouvez pas activer les instances à partir d'un file unité qui se trouve dans un path non standard (voir https://github.com/systemd/systemd/issues/661 )