Debian systemd network-online.target funktioniert nicht?

24

Ich versuche, einen Systemdienst für Debian Jessie zu erstellen. Ich brauche es, um zu starten, nachdem network-online.targetes erreicht ist.

Das Problem ist, dass network-online.targetgleichzeitig mit network.targetund zu diesem Zeitpunkt meine Schnittstellen noch nicht konfiguriert sind, nur die DHCP-Abfrage gestartet wurde.

Es sieht so aus, als ob dieses Problem spezifisch für Debian ist, da es eine alte Netzwerkkonfiguration verwendet.

Wie kann man dieses Problem umgehen oder network-online.targetarbeiten lassen?

debian systemd systemd-networkd

— 10robinho
quelle

Was ist die Ausgabe von systemctl list-dependencies network-online.target? Beachten Sie auch, dass dies network-online.targetmöglicherweise nicht zwingend bedeutet, dass ein Internetzugang vorhanden ist. Weitere Informationen finden Sie auf dieser Seite.

— Saiarcot895

Die Ausgabe des Befehls lautet: network-online.target ● └─systemd-networkd-wait-online.service Ich habe diese Seite bereits gelesen, ich verstehe das Grundkonzept dort, aber es ist immer noch sehr seltsam, keinen definierten Punkt zu haben, an dem netzwerkkritische Dienste starten können. Zumindest könnte es auf eine ordnungsgemäße DHCP-Zuweisung warten.

— 10robinho,

Das bedeutet, dass das network-online.targetnur von dem systemd-networkd-wait-online.serviceSpruch abhängt , dass es fertig ist. Es hängt nicht davon ab, ob NetworkManager sagt, dass es bereit ist, oder ob überprüft wird, ob ifupalle Verknüpfungen erfolgreich hergestellt wurden (wenn Sie diese Methode zum Konfigurieren Ihres Netzwerks verwenden). Ubuntu hingegen ist abhängig von ifupund NetworkManager, jedoch nicht für systemd-networkd-wait-online..

— Saiarcot895

Wie konfigurieren Sie Ihr Netzwerk /etc/network/interfaces:, .networkSystemdateien oder NetworkManager?

— Saiarcot895

Sie haben Recht network-online.targetund network.targetwerden gleich danach ausgelöst ifup. Ich verwende Debian-Standard, also /etc/network/interfacesmit DHCP-Adresse. Es sieht so aus, als ob networkd eine bessere Lösung sein könnte, aber die Implementierung ist nicht einfach.

— 10robinho

18

Da Sie verwenden /etc/network/interfaces, benötigen Sie einen System-Service, um den Status jeder Schnittstelle zu überwachen. Überprüfen Sie, ob dies der Fall ist /lib/systemd/system/ifup-wait-all-auto.service(installiert durch das ifupdownPaket in Ubuntu 15.04). Wenn nicht, erstellen Sie /etc/systemd/system/ifup-wait-all-auto.serviceFolgendes und fügen Sie es ein:

[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

Dies ist die Service-Datei, wie sie auf einem Ubuntu 15.04-System vorhanden ist, jedoch mit dem [Install]Abschnitt, der hinzugefügt wurde, um die Dinge ein wenig einfacher zu machen. Ich hoffe, dass das Verhalten ifupin Ubuntu 15.04 dem Verhalten ifupin Debian Jessie entspricht. Andernfalls sind einige Änderungen erforderlich (insbesondere bei der letzten Zeile).

Dann renne sudo systemctl enable ifup-wait-all-auto.service. Nach dem Neustart Ihres Computers sollten Sie feststellen, dass der network-online.targetnach dem Aufrufen der Schnittstellen erreicht ist (zumindest).

— saiarcot895
quelle

Vielen Dank für die Mühe, lassen Sie es mich jetzt versuchen und ich gebe Ihnen Feedback

— 10robinho

Am Ende habe ich eine leicht modifizierte Version ausgeführt ExecStart = /bin/bash -c 'while [ -z "$(hostname -I)" ]; do sleep 1; done;'. Es hängt davon ab hostname, ob eine IP-Adresse zugewiesen wurde.

— luka5z

Versuchen Sie nicht, es zu schleudern. Es liegt nicht daran, dass er / etc / network / interfaces verwendet. Das liegt daran, dass systemd so schlampig ist und die Arbeit an jeden Benutzer ausgelagert wird, anstatt das Problem dort zu lösen, wo sie erstellt wurde.

— Florian Heigl

1

fwiw, die ifup-wait-all-auto.servicewurde in der ifupdownversion fallen gelassen 0.8.5ubuntu1: ”drop ifup-wait-all-auto.service. Dies wurde eleganter implementiert, indem network-online.target Wants = networking.service direkt

— aktiviert wurde

0

Beachtung! Fand es einfach auf einem Raspbian Jessie heraus: Entferne ALLE kommentierten Zeilen in / etc / network interfaces und es wird funktionieren! Es scheint ein Parsing-Fehler zu sein =) In meinem speziellen Fall habe ich iface eth0 inet dhcpes vor Äonen kommentiert und einfach vergessen, aber nach dem Upgrade auf Raspbian Jessie und der Neuerstellung eines Kernels habe ich ein sehr merkwürdiges Verhalten: Es hat DHCP verwendet und dies abgelehnt Tuning aus / etc / network / interfaces. Also habe ich alle Kommentare entfernt - nur funktionierende Zeilen, Neustart - und es funktioniert! KEIN SCRIPT PATCHING / EDITING NOTWENDIG!

— Alexey Vesnin
quelle

Interessant, ich muss das versuchen. Obwohl es nicht viel Sinn macht :)

— 10robinho

2

Haben Sie Referenzen dazu? Ich möchte die Fehlerberichte lesen und den Fehlercode sehen.

— Sonntag,

Nein, ich habe kein Fehlerticket geöffnet. Um es zu reproduzieren, fügen Sie einfach einige Kommentare in Ihre /etc/network/interfacesDatei ein - es wird gestartet, wenn es noch da ist.

— Alexey Vesnin

0

Laut https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ ist die Verwendung von " network-online.target " in der .service- Datei die empfohlene Methode zum Starten eines Dienstes, nachdem die Netzwerkebene erreicht ist :

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

Nachdem ich jedoch " network-online.target " verwendet hatte und mein Dienst fehlgeschlagen war, weil das Netzwerk nicht voll funktionsfähig war, stellte ich fest, dass ein Fehler ( https://github.com/coreos/bugs/issues/1966 ) vorliegt: dies kann nicht garantiert werden 100% unfehlbar sein.

Wenn dynamische Netzwerkkonfigurationstools wie " NetworkManager " wie in diesem Fall verwendet werden, kann der Netzwerkstatus niemals 100% genau oder vorhersehbar sein. Anscheinend kann sich " network-online.target " von dem Link, der den Fehler beschreibt, abhängig von den verschiedenen Anwendungen, mit denen es verwendet wird, inkonsistent verhalten.

Problemumgehung :
Sie müssen die Startreihenfolge der Dienste analysieren und einen Dienst verwenden, der später als " network-online.target " startet :

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

Dies ist ein iterativer Prozess, bei dem die Ziele schrittweise auf spätere und spätere Dienste geändert werden, bis Sie denjenigen finden, der sicherstellt, dass das Netzwerk auf einem Level ist und Ihr Dienst fehlerfrei gestartet wird. In meinem eigenen Fall musste ich sogar einen sleep 10in meinem Skript aufgerufenen SystemD-Dienst einstellen.

— F1Linux
quelle

0

Ich habe einmal eine Antwort auf Github gefunden , die es löste, indem ich ständig versuchte, einen Server zu pingen. Erst wenn der Ping eingeht, wird der Dienst fortgesetzt:

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

Ich habe durch google.commeinen eigenen Server ersetzt, weil mein Hauptskript eine Verbindung zu meinem Server herstellen musste.

— Sam
quelle