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

En ce moment, j'essaie de comprendre comment faire fonctionner un script shell personnalisé. Ce script doit être exécuté après la couche réseau a démarré.

J'utilise Arch, en utilisant systemd ainsi que netctl.

Pour tester, j'ai écrit un script simple qui 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 s'exécute effectivement, mais il s'exécute avant le démarrage du réseau. En d'autres termes, la sortie dans ip.txt n'affiche aucune adresse IPv4 attribuée à l'interface principale. Au moment où je me connecte, l'adresse IPv4 a bien été attribuée et le réseau est opérationnel.

Je suppose que je pourrais modifier le point auquel le script s'exécute en jouant avec le WantedBy paramètre, mais je ne sais pas comment faire.

Quelqu'un pourrait-il m'orienter dans la bonne direction ?

Réponse acceptée :

Sur les dépendances de configuration réseau systemd

Il est très facile d'affecter l'ordre des unités de systemd. D'un autre côté, vous devez faire attention à ce qu'une unité terminée garantit.

Configurez votre service

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

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

Pour la compatibilité avec les systèmes plus anciens, vous devrez peut-être également 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.

Mise en œuvre dans les versions actuelles du logiciel

Vous devez maintenant vous assurer que network-online.target fonctionne comme prévu (ou que vous pouvez au moins utiliser network.target ).

La version actuelle de NetworkManager propose le NetworkManager-wait-online.service qui est tiré par network-online.target et donc par votre service. Ce service spécial garantit que votre service attendra jusqu'à ce que toutes les connexions configurées pour être démarrées automatiquement réussissent, échouent ou expirent.

La version actuelle de systemd-networkd bloque votre service jusqu'à ce que tous les appareils soient configurés comme demandé. Il est plus simple car il ne prend actuellement en charge que les configurations appliquées au démarrage (plus précisément au démarrage de `systemd-networkd.service).

Par souci d'exhaustivité, le /etc/init.d/network service dans Fedora, tel qu'interprété par les versions actuelles de systemd, bloque network.target et bloque donc indirectement network-online.target et 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, ait échoué pour une bonne raison ou ait expiré après un délai raisonnable. cadre à compléter.

Connexe :Rechercher des fichiers dont les noms de chemin contiennent plusieurs mots sans ordre spécifique entre eux ?

Vous voudrez peut-être vérifier si netctl fonctionne de la même manière et cette information serait 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'au moins network-online.target existe et qu'il est commandé après network.target .

Anciennement NetworkManager seulement garanti qu'au moins une connexion serait appliquée. Et même pour que cela fonctionne, vous devez activer le NetworkManager-wait-online.service explicitement. Cela a été corrigé depuis longtemps dans Fedora mais n'a été appliqué que récemment en amont.

systemctl enable NetworkManager-wait-online.service

Remarques sur les implémentations de network.target et network-online.target

Vous ne devriez jamais avoir besoin de faire dépendre votre logiciel de NetworkManager.service ou NetworkManager-wait-online.service ni aucun autre service spécifique. Au lieu de cela, tous les services de gestion de réseau doivent se commander avant network.target et é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.target et 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.target même si ce n'est pas très utile.

[Unit]
Before=network.target

[Service]
Type=simple
ExecStart=...

Un service qui attend que le démon se termine doit s'ordonner après le service spécifique et avant network-online.target . Il doit utiliser Requisite sur le service démon afin qu'il échoue immédiatement si le service de gestion de réseau respectif 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 wants répertoire pour network-online.target afin qu'il soit attiré par les services qui veulent attendre le réseau configuré.

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

Documentation associée

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

Remarques finales

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