Abhängig von der Distribution ip link set <iface> upwerden beim Aufrufen (oder Herunterfahren; auch ifup / ifdown) verschiedene Konfigurationsdateien (/etc/network/interfaces unter Debian, glaube ich, Gentoo hat /etc/conf.d/net...) durchsucht und Änderungen vorgenommen (z. B. Interaktion mit DHCP usw.).
Soweit ich es gesehen habe strace, kommuniziert der ipBefehl direkt mit dem Kernel (ist das so?). Aber dann startet irgendwann jemand diese Shell-Skripte bzw. liest die Konfiguration. Welcher Mechanismus steckt dahinter? Lauscht das Init-System auf einer Kernel-Schnittstelle auf Änderungen des Up-/Down-Status und startet diese Skripte? Oder ist es etwas anderes?
Antwort1
Der Aufruf ip link set <iface> up, wie Sie ihn beschreiben, ist lediglich eine minimale Kommunikation mit dem Kernel über dasrtnetlinkAPI(dabei geht es nicht nur um Routen, sondern auch um Links, Adressen usw. Hier wäre das RTM_NEWLINK), um die Schnittstelle administrativ zu aktivieren. Ältere ifconfigTools fragen den Kernel unter Verwendung der (für das Netzwerk) veralteten ioctl-API nach demselben Problem (hier wäre das SIOCGIFFLAGS).
Bei diesen Befehlen handelt es sich um Befehle auf niedriger Ebene, die nur das tun, was verlangt wurde, und nichts weiter.
ifupist Teil (unter Debian) deswennauf(oder die alternativeifupdown2) Suite und hat unterschiedliche Implementierungen auf verschiedenen Linux-Distributionen. Sie sind nur eine Suite von Skripten, die sich wahrscheinlich ip link set ...selbst aufrufen, und vielleicht verwenden einige von ihnen auch direkt andere verfügbare Tools (wieNetzwerk Manager). Man kann sie also absolut nicht auf die gleiche Stufe stellen: ip link set ... upist überhaupt nicht ifup ....
Wie würden nun andere Netzwerktools wieNetzwerk Managerinteragieren und wissen, was passiert ist? Weil sie den Kernel fragen, durchrtnetlink, um über Netzwerk-Events informiert zu werden, die sie interessieren.NetzlinkDie API-Implementierung unterstützt Multicast: Das bedeutet, dass eine einzelne Nachricht effizient von mehreren interessierten Parteien (aus dem Benutzerbereich oder Kernel) empfangen werden kann, was die Ereignisimplementierung vereinfacht.
Wenn etwas (hier ip link set ... up) eine Nachricht an den Kernel sendet, antwortet der Kernel normalerweise mit einer Nachricht, die per Multicast an die interessierten Parteien gesendet wird: Der ip linkBefehl erhält diese Nachricht zurück, aber auch alle wartenden Tools, die jetzt wissen, dass „gerade eine Schnittstelle aufgerufen wurde“ (die Unterschiede zwischen dem Verwaltungsstatus „aktiv“ und dem Betriebsstatus „aktiv“ lasse ich hier einmal außer Acht).
Es ist möglich, dasselbe in einem Skript mithilfe einer Ereignisschleife zu tun, die von der Ausgabe des Befehls gesteuert wird.ip monitordie auf Netzwerkereignisse vom Kernel wartet. Natürlich wäre eine wirklich analysierbare Ausgabe wünschenswert, leider, während viele andereiproute2Unterbefehle unterstützen eine JSON-Ausgabe (mithilfe von -json), was bei nicht der Fall ist ip monitor.
Hier ist einBasicShell-Beispiel basierend auf ip monitor linkder Anzeige des Oper-Status einer Schnittstelle, wenn eine Änderung an dieser Schnittstelle vorgenommen wird (auch wenn sie nicht mit ihrem Oper-Status zusammenhängt. Das ist eineBasicBeispiel). Da die Ausgabe unzuverlässig ist, kann es in einigen Fällen zu Fehlern kommen:
#!/bin/sh
ip -o monitor link | while read -r index interface status remaining; do
iface=$(printf '%s\n' "$interface" | sed -E 's/(@.*)?:$//')
operstate=$(printf '%s\n' "$remaining" | grep -Eo ' state [^ ]+' | sed 's/^ state //')
printf '%s %s\n' "$iface" "$operstate"
done
Während das obige Skript ausgeführt wird, versuchen Sie diese Befehle an anderer Stelle:
# ip link add test1 type veth peer name test2
# ip link set test1 up
# ip link set test2 up
# ip link delete test1 # script doesn't handle correctly lines starting with Deleted
Dasselbe ist mit Adressen, Routen usw. möglich. So funktionieren Tools wieNetzwerk Managerreagieren auf den Befehl ip link set <iface> up.