Je suis relativement nouveau chez systemd et j'apprends son architecture.

En ce moment, j'essaie de trouver un moyen d'exécuter un script shell personnalisé. Ce script doit être exécuté après le démarrage de la couche réseau.

J'utilise Arch, en utilisant systemd et netctl.

Pour tester, j'ai écrit un script simple qui s'exécute simplement ip addr list > /tmp/ip.txt. J'ai créé le fichier de service suivant pour ce script.

(/etc/systemd/system/test.service)
[Unit]
Description=test service

[Service]
ExecStart=/root/test.script

[Install]
WantedBy=multi-user.target

J'ai ensuite activé le script avec,

systemctl enable test

Au redémarrage, le script est effectivement exécuté, mais il est exécuté avant le démarrage du réseau. En d'autres termes, la sortie dans ip.txtn'affiche aucune adresse IPv4 attribuée à l'interface principale. Au moment de ma connexion, l'adresse IPv4 a bien été attribuée et la mise en réseau est terminée.

Je suppose que je pourrais modifier le point auquel le script est exécuté en modifiant le WantedByparamètre, mais je ne sais pas comment faire.

Quelqu'un peut-il m'indiquer la bonne direction?

Dépendances de la configuration réseau de systemd

Il est très facile d’affecter la commande d’unités de systemd. D'autre part, vous devez faire attention à ce qu'une unité achevée garantit.

Configurez votre service

Sur les systèmes actuels, commander après network.targetgarantit simplement que le service réseau a été démarré, et non qu'il existe une configuration réelle. Vous devez commander après network-online.targetet le tirer pour y parvenir.

[Unit]
Wants=network-online.target
After=network-online.target

Pour assurer la compatibilité avec les systèmes plus anciens, vous devrez peut-être aussi commander après network.target.

[Unit]
Wants=network-online.target
After=network.target network-online.target

C'est pour le fichier d'unité de votre service et pour systemd.

Implémentation dans les versions actuelles du logiciel

Maintenant, vous devez vous assurer que cela network-online.targetfonctionne comme prévu (ou que vous pouvez au moins l'utiliser network.target).

La version actuelle de NetworkManager offre le NetworkManager-wait-online.servicequi est tiré par network-online.targetet donc par votre service. Ce service spécial garantit que votre service attendra que toutes les connexions configurées pour être démarrées réussissent, échouent ou dépassent automatiquement le délai imparti.

La version actuelle de systemd-networkd bloque votre service jusqu'à ce que tous les périphériques soient configurés comme demandé. Il est plus facile dans la mesure où il ne prend actuellement en charge que les configurations appliquées au démarrage (plus précisément au moment du démarrage de `systemd-networkd.service).

Par souci d'exhaustivité, le /etc/init.d/networkservice dans Fedora, tel qu'interprété par les versions actuelles de systemd, bloque network.targetet donc, indirectement, bloque network-online.targetet votre service. C'est un exemple d'implémentation basée sur un script.

Si votre implémentation, qu'elle soit basée sur un démon ou sur un script, se comporte comme l'un des services de gestion de réseau ci-dessus, elle retardera le démarrage de votre service jusqu'à ce que la configuration du réseau soit terminée avec succès, échoue pour une bonne raison ou expire après un délai raisonnable. cadre à compléter.

Vous voudrez peut-être vérifier si netctl fonctionne de la même manière et que ces informations constitueraient un ajout précieux à cette réponse.

Implémentations dans les anciennes versions du logiciel

Je ne pense pas que vous verrez une version suffisamment ancienne de systemd où cela ne fonctionnerait pas bien. Mais vous pouvez vérifier qu'il network-online.targetexiste au moins et qu'il est commandé après network.target.

Auparavant, NetworkManager garantissait uniquement qu’au moins une connexion serait appliquée. Et même pour que cela fonctionne, vous devez l'activer NetworkManager-wait-online.serviceexplicitement. Ce problème a été corrigé depuis longtemps dans Fedora, mais il n'a été appliqué que récemment en amont.

systemctl enable NetworkManager-wait-online.service

Notes sur les implémentations network.target et network-online.target

Vous ne devriez pas avoir besoin de faire de votre logiciel dépendra NetworkManager.serviceou NetworkManager-wait-online.serviceni aucun autre services. Au lieu de cela, tous les services de gestion de réseau doivent se commander avant network.targetet éventuellement network-online.target.

Un simple service de gestion de réseau basé sur un script doit terminer la configuration du réseau avant de quitter et doit se commander avant network.targetet donc indirectement avant network-online.target.

[Unit]
Before=network.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

Un service de gestion de réseau basé sur un démon doit également se commander avant network.targetmême s’il n’est pas très utile.

[Unit]
Before=network.target

[Service]
Type=simple
ExecStart=...

Un service qui attend la fin du démon doit se commander lui-même après le service spécifique et avant network-online.target. Il doit utiliser Requisitele service démon pour qu’il échoue immédiatement si le service de gestion de réseau correspondant n’est pas utilisé.

[Unit]
Requisite=...
After=...
Before=network-online.target

[Service]
Type=oneshot
ExecStart=...
RemainAfterExit=yes

Le paquet doit installer un lien symbolique vers le service en attente dans le wantsrépertoire network-online.targetafin que celui-ci soit attiré par les services qui souhaitent attendre le réseau configuré.

ln -s /usr/lib/systemd/system/... /usr/lib/systemd/system/network-online.target.wants/

Documentation connexe

• http://www.freedesktop.org/software/systemd/man/systemd.special.html#network-online.target
• http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Notes finales

J'espère avoir non seulement aidé à répondre à votre question au moment où vous l'avez posée, mais également à améliorer la situation des distributions amont et Linux, afin que je puisse maintenant donner une meilleure réponse que celle qui était possible au moment de la rédaction de l'original. .

Vous pouvez utiliser Afterdans la [Unit]section pour définir un service devant être démarré avant le démarrage de votre service. Par exemple, si vous utilisez NetworkManager, vous pouvez faire démarrer votre service après le démarrage de NetworkManager.

[Unit]
Description=test service
After=NetworkManager.service

Si votre service fournit un serveur pouvant attendre passivement que quelqu'un s'y connecte, utilisez ceci:

[Unit]
After=network.target

Votre service doit être lié sur l'interface générique. S'il utilise l'activation de socket (recommandé) ou s'il est uniquement local, vous pouvez ignorer complètement les cibles réseau.

Si votre service agit en tant que client, ou est peer to peer, ceci est plus approprié:

[Unit]
After=network-online.target
Requires=network-online.target

Avant la version 213 , network-online.target a besoin de la solution mentionnée par Pavel (vous devez activer manuellement un service qui attend que le réseau soit opérationnel). A partir de la version 213, cela est fait par défaut. systemd-networkd-wait-onlineattendra qu’au moins une adresse (routable ou link-local) soit configurée sur une interface sans bouclage.

La configuration de systemd-networkd, NetworkManager ou équivalente est une tâche indépendante. Les protocoles DHCP (pour IPv4) et NDP (pour IPv6) ont tendance à fonctionner immédiatement, mais vous devez les configurer de manière à ce que votre définition précise de «le réseau est opérationnel» déclenche network-online.target.

Documentation:

• network.target
• network-online.target
• Exécution des services après la mise en place du réseau

J'imagine que je pourrais modifier le point d'exécution du script en jouant avec le paramètre WantedBy.

Cela aura l'effet inverse de ce que vous voulez. De man systemd.unit:

WantedBy =, RequiredBy =

[...] Un lien symbolique est créé dans le répertoire .wants / ou .requires / de chacune des unités répertoriées lorsque cette unité est installée par systemctl enable. Cela a pour effet qu'une dépendance de type Wants = ou Requise = est ajoutée à partir de l' unité listée à l' unité en cours .

Sur cette base, nous pouvons voir que l’unité appropriée est "veut" ou "nécessite"; sur la base de la description de ceux-ci, "Nécessite" est probablement correcte, avec l'ajout de "Après" pour garantir non seulement que le service de réseau soit exécuté, mais également avant.

Aucune des options de l'unité, autant que je sache, ne peut spécifier qu'un perquis démarré doit avoir été terminé ou atteint un certain point (la mise en réseau est probablement un service démon), mais uniquement qu'il doit être démarré en premier. Dans cet esprit, vous voudrez peut-être créer votre script Type=forkinget lui attribuer un délai normal (par exemple 30 secondes) ou une sorte de boucle de sortie avec succès, y compris un délai, afin de vous assurer que vous disposez en premier d'un bail DHCP.

Utilisez Afterdans la [Unit]section pour spécifier ce qui doit être démarré avant votre propre service. (Cette partie de la réponse précédente est correcte.)

Pour démarrer votre service une fois le réseau mis en place, utilisez la cible réseau, que vous utilisiez NetworkManager, le système conf.d / netctl dans Arch ou tout autre service connu par systemd.

[Unit]
#.....
After=network.target

Un bref aperçu confirmera que tous les autres services de votre système reposant sur la connectivité réseau contiennent cette directive.

Il est également portable pour toute distribution utilisant systemd. Votre fichier d’unités sera le même pour Arch, Fedora, RHEL 7, les futures versions de Debian ...

Les services qui démarrent une connexion réseau, tels que les scripts d'Arch ou les vôtres, doivent le spécifier dans leurs propres fichiers d'unité.

[Unit]
Wants=network.target
Before=network.target

Je voulais ajouter un point à cet article. Actuellement (été 2015) dans RHEL7 / CentOS 7, network-online.target est défini de manière incorrecte avant la mise en réseau IPv6, de sorte que les démons ayant

Wants=network-online.target
After=network-online.target

dans leur définition de service, qui se lient aussi explicitement aux adresses IPv6, seront probablement lancées avant qu'IPv6 ne soit opérationnel et en cours d'exécution, ce qui entraînerait leur défaillance.

[Unit]
After=systemd-networkd.service

travaille pour moi.