Debian systemd network-online.target ne fonctionne pas?

24

J'essaie de créer un service systemd sur Debian Jessie. J'en ai besoin pour commencer une fois network-online.targetatteint.

Le problème est que les network-online.targetincendies se produisent en même temps network.targetet qu'à ce moment-là mes interfaces ne sont pas encore configurées, vient de lancer la requête DHCP.

Il semble que ce problème soit spécifique à Debian car il utilise la configuration réseau héritée.

Comment contourner ce problème ou comment faire network-online.targetfonctionner?

debian systemd systemd-networkd

— 10robinho
source

Quelle est la sortie de systemctl list-dependencies network-online.target? Sachez également que network-online.targetcela ne signifie pas nécessairement qu'il existe un accès Internet. Voir cette page pour plus d'informations.

— saiarcot895 du

La sortie de la commande est: network-online.target ● └─systemd-networkd-wait-online.service j'ai déjà lu cette page, je comprends le concept de base là-bas, mais il est toujours très étrange de ne pas avoir de point défini où les services critiques du réseau peuvent démarrer. Au moins, il pourrait attendre une affectation DHCP appropriée.

— 10robinho

Cela signifie que le network-online.targetdépend uniquement du systemd-networkd-wait-online.servicedicton qu'il est prêt. Cela ne dépend pas du fait que NetworkManager soit prêt, ni de vérifier que ifuptous les liens ont réussi (si vous utilisez cette méthode pour configurer votre réseau). Ubuntu, en revanche, dépend de ifupet de NetworkManager, mais pas pour systemd-networkd-wait-online..

— saiarcot895

Comment configurez-vous votre réseau /etc/network/interfaces:, les .networkfichiers systemd ou NetworkManager?

— saiarcot895

Vous avez raison network-online.targetet vous network.targetdéclenchez juste après ifup. J'utilise Debian par défaut, donc /etc/network/interfacesavec l'adresse DHCP. Il semble que networkd pourrait être une meilleure solution, mais sa mise en œuvre n'est pas simple.

— 10robinho

18

Puisque vous utilisez /etc/network/interfaces, vous aurez besoin d'un service systemd pour surveiller l'état de chaque interface. Vérifiez si vous en avez /lib/systemd/system/ifup-wait-all-auto.service(installé par le ifupdownpaquet dans Ubuntu 15.04). Sinon, créez /etc/systemd/system/ifup-wait-all-auto.serviceet collez les éléments suivants:

[Unit]
Description=Wait for all "auto" /etc/network/interfaces to be up for network-online.target
Documentation=man:interfaces(5) man:ifup(8)
DefaultDependencies=no
After=local-fs.target
Before=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutStartSec=2min
ExecStart=/bin/sh -ec '\
  for i in $(ifquery --list --exclude lo --allow auto); do INTERFACES="$INTERFACES$i "; done; \
  [ -n "$INTERFACES" ] || exit 0; \
  while ! ifquery --state $INTERFACES >/dev/null; do sleep 1; done; \
  for i in $INTERFACES; do while [ -e /run/network/ifup-$i.pid ]; do sleep 0.2; done; done'

[Install]
WantedBy=network-online.target

Il s'agit du fichier de service présent sur un système Ubuntu 15.04, mais avec la [Install]section ajoutée pour faciliter les choses. J'espère que le comportement de ifupUbuntu 15.04 est le même que celui de ifupDebian Jessie. Sinon, une modification sera nécessaire (notamment avec la dernière ligne).

Ensuite, courez sudo systemctl enable ifup-wait-all-auto.service. Après le redémarrage de votre ordinateur, vous devriez voir que le network-online.targetest atteint après que les interfaces ont été lancées (au moins).

— saiarcot895
source

Merci pour l'effort, permettez-moi de l'essayer maintenant et je vous donnerai vos commentaires

— 10robinho

J'ai fini par exécuter une version légèrement modifiée ExecStart = /bin/bash -c 'while [ -z "$(hostname -I)" ]; do sleep 1; done;'. Cela dépend hostnamede vérifier si l'adresse IP a été attribuée.

— luka5z

N'essayez pas de l'essayer. ce n'est pas parce qu'il utilise / etc / network / interfaces. C'est parce que systemd est tellement bâclé et le travail est déchargé pour chaque utilisateur au lieu de résoudre le problème où il a été créé.

— Florian Heigl

1

fwiw, le ifup-wait-all-auto.servicea été supprimé dans la ifupdownversion 0.8.5ubuntu1: ”Drop ifup-wait-all-auto.service. Cela a été mis en œuvre de manière plus élégante en faisant directement

— network-online.target

0

Attention! Je viens de le comprendre sur un Raspbian Jessie: supprimez TOUTES les lignes commentées dans les interfaces / etc / network et cela fonctionnera! Cela semble être un bug d'analyse =) Dans mon cas spécifique, j'ai laissé un commentaire iface eth0 inet dhcpet je l'ai juste oublié il y a des éons, mais après la mise à niveau vers Raspbian Jessie et la reconstruction d'un noyau, j'ai un comportement très étrange: il a utilisé DHCP et a refusé de faire un réglage à partir de / etc / network / interfaces. Je l'ai donc retiré de tout commentaire - juste des lignes de travail, redémarrez - et cela fonctionne! AUCUN PATCH / ÉDITION DE SCRIPT NÉCESSAIRE!

— Alexey Vesnin
source

Interestin, je dois essayer ça. Même si cela n'a pas beaucoup de sens :)

— 10robinho

2

Avez-vous des références à ce sujet? Je voudrais lire le (s) rapport (s) de bogue et voir le code du bogue.

— ʇsәɹoɈ

Non, je n'ai pas ouvert de ticket de bogue. Pour le reproduire, ajoutez simplement quelques commentaires dans votre /etc/network/interfacesfichier - il se déclenchera s'il est toujours là.

— Alexey Vesnin

0

Par https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ la façon recommandée de démarrer un service APRÈS la mise en réseau est de niveau est d'utiliser " network-online.target " dans le fichier .service :

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

Cependant, après avoir utilisé " network-online.target " et mon service a échoué parce que la mise en réseau n'était pas complètement au niveau, j'ai découvert qu'il y avait un bogue ( https://github.com/coreos/bugs/issues/1966 ) avec: non garanti être 100% infaillible.

En effet, lorsque des outils de configuration de réseau dynamique tels que " NetworkManager " sont utilisés comme dans ce cas, l'état du réseau ne peut jamais être précis ou prévisible à 100%. Apparemment, à partir du lien décrivant le bogue, " network-online.target " peut se comporter de manière incohérente selon les différentes applications avec lesquelles il est utilisé.

Solution :
vous devez analyser l'ordre de démarrage des services et en utiliser un qui démarre plus tard que " network-online.target ":

 systemd-analyze plot > /home/pi/graph.svg

Il s'agit d'un processus itératif qui modifie progressivement les cibles en services de plus en plus récents jusqu'à ce que vous trouviez celui qui garantit que le réseau est de niveau et que votre service démarre sans erreur. Dans mon propre cas, j'ai même dû mettre sleep 10dans mon script le service SystemD appelé.

— F1Linux
source

0

J'ai trouvé une fois une réponse sur Github qui l'a résolue en essayant continuellement de cingler un serveur. Ce n'est que lorsque le ping arrive, que le service continue:

[Service]
ExecStartPre=/bin/sh -c 'until ping -c1 google.com; do sleep 1; done;'
ExecStart=<your command>

J'ai remplacé google.compar mon propre serveur car mon script principal devait se connecter à mon serveur.

— Sam
source