Welcher Linux-Prozess ist für die Beantwortung von Pings verantwortlich?

Ich habe einen Linux-basierten Prozess-Controller, der gelegentlich bis zu dem Punkt blockiert, an dem Sie kein Ping mehr durchführen können (dh, ich kann ein Ping durchführen, ohne dass Änderungen an den Netzwerkeinstellungen vorgenommen werden müssen).

Ich bin gespannt, welcher Prozess / welches System dafür verantwortlich ist, tatsächlich auf Pings zu reagieren. Es scheint, dass dieser Prozess abstürzt.

network-interface ping icmp

— Izzo
quelle

Können Sie immer noch darauf zugreifen, während es nicht auf Pings reagiert? Oder blockieren bestehende SSH-Sitzungen?

— Peter Cordes

@PeterCordes Das gesamte System stürzt ab und ist im Wesentlichen ein Baustein, bis ein Neustart erzwungen wird.

— Izzo

Ok, das ist normalerweise die einzige Möglichkeit, dass ein Computer nicht mehr auf Pings reagiert. Es wäre seltsam, wenn Pings nicht mehr funktionieren würden, andere Dinge jedoch weiter funktionieren würden, da die Ping-Verarbeitung auch dann funktioniert, wenn der Benutzerplatz knapp wird und alle Daten auf der E / A-Festplatte auf eine nicht funktionierende Festplatte oder ein NFS-Mount oder was auch immer blockiert sind. Versuchen Sie, einen Monitor an Ihr System anzuschließen, und prüfen Sie, ob eine Konsolenmeldung angezeigt wird, wenn der Monitor abstürzt. (Und wenn Sie die magischen SysRQ-Tastatursequenzen verwenden können, um Informationen zu sichern, oder um sie nur noch einmal zu laden, müssen Sie die Laufwerke zwangsweise synchronisieren und neu starten.

— Peter Cordes,

Obwohl Ihre Frage interessant ist, ist Ping nicht die Ursache für die Probleme Ihres Systems, sondern eine Folge eines instabilen Systems. Überprüfen Sie die Protokolle, um zu verstehen, was falsch ist.

— Pedro Lobito

@PedroLobito Was protokolliert speziell?

— Izzo

Antworten:

Der Kernel-Netzwerkstapel verarbeitet ICMP-Nachrichten, die vom pingBefehl gesendet werden .

Wenn Sie keine Antworten erhalten, außer Netzwerkproblemen oder Filtern und hostbasiertem Filtern / Ratenbegrenzung / Black-Holing / etc. Dies bedeutet, dass die Maschine wahrscheinlich von etwas überlastet ist, das vorübergehend sein kann, oder dass der Kernel abgestürzt ist, was selten vorkommt, aber passieren kann (fehlerhafte Hardware usw.), und zwar nicht unbedingt aufgrund des ICMP-Verkehrs (aber des Versuchs, ihn mit solchem Verkehr zu überlasten) kann ein guter Test zu Beginn eines Serverlebens sein, um zu sehen, wie es die Dinge stützt). Im späteren Fall eines Kernel-Absturzes sollten Sie reichlich Informationen in den Protokolldateien oder auf der Konsole haben.

Beachten Sie auch, dass dies pingfast immer das falsche Tool ist, um zu überprüfen, ob ein Dienst online ist oder nicht. Aus verschiedenen Gründen, vor allem aber, weil es per Definition keinen echten Anwendungsverkehr nachahmt. Wenn Sie beispielsweise überprüfen möchten, ob ein Webserver noch aktiv ist, sollten Sie stattdessen eine HTTP-Abfrage durchführen (TCP-Port 80 oder 443). Wenn Sie einen Mailserver überprüfen möchten, führen Sie eine SMTP-Abfrage durch (TCP-Port 25) einen DNS-Server, eine UDP- und eine TCP-Abfrage an Port 53 usw.

— Patrick Mevzek
quelle

@Outurnate Alle anderen Tests für Anwendungsdienste schlagen fehl oder haben eine Zeitüberschreitung, sodass das beobachtete Endergebnis dasselbe ist. Ich verpasse nie eine Gelegenheit, einen Vortrag gegen die Verwendung von zu halten, pingda dies bei der Fehlerbehebung viel zu viele Fehlalarme hervorruft. Daher denke ich, dass Benutzer, die nicht genau wissen, was Ping bewirkt und wie es zu irreführenden Ergebnissen führen kann, bei etwas anderem bleiben sollten.

— Patrick Mevzek

In den meisten Überlastungssituationen reagieren nur noch die Dinge, die vom Kernel ausgeführt werden. Das bedeutet, dass eine Maschine normalerweise auf Ping reagiert, unabhängig davon, wie überlastet sie ist. Versuche, einen geschlossenen Port zu erreichen, werden mit RST für TCP und einem ICMP-Fehler im Falle von UDP beantwortet. Die ersten Versuche, einen offenen TCP-Port zu erreichen, führen zu einem Handshake. Ein Festplattenfehler kann zu fast denselben Symptomen führen.

— Kasperd

@kasperd Ich habe (sehr) überlastete Server gesehen (die speziell ausgetauscht wurden), die auch nicht auf ICMP-Anfragen geantwortet haben. Und natürlich auch zu nichts anderem. Der Kernel stürzte nicht ab, sondern war nur mit Datenträger-E / A-Aufgaben beschäftigt.

— Patrick Mevzek

@Nacht Yup. Eine Netzwerkschnittstelle ist ein Hardware-Gerät. Als solches gibt es einen Kerneltreiber, der mit ihm verbunden werden kann. Eine zweite Schicht stellt dann allgemeine Verwaltungs- / Kommunikations-APIs bereit. (Dies gilt nicht nur für das Netzwerk: Es gibt ALSA für Audio-Entwickler, Video-Ausgänge verwenden die KMS-API, USB hat {U, E, X} HCI, dann usb_storage, usbhid usw.) Netzwerk-Routing-Tabellen, Firewall-Regeln (über iptables) ), Handshake, Paketzusammenstellung, erneute Übertragungen usw. sind alle im Kernel. Da ICMP ein Protokoll für sich ist, ohne Nutzlast und ohne Verarbeitung, die über "Antworten oder Nicht-Antworten" hinausgeht, verarbeitet der Kernel ICMP-Antworten direkt, um den Overhead zu minimieren.

— FeRD

@Nacht: Es geht nicht wirklich um grundlegende Computerarchitektur; Es ist eine Wahl der Implementierung. Mikrokerne verarbeiten ICMP in einem Betriebssystemprozess.

— MSalters

Es gibt keinen Userland-Prozess, der für die Beantwortung von Pings verantwortlich ist. Ping ist nur ein Dienstprogramm zum Senden von ICMP-Echopaketen. Diese werden vom Netzwerkstapel des Kernels empfangen und verarbeitet

— Outurnate
quelle

Der Kernel selbst (kein Benutzerprozess) ist dafür verantwortlich, ICMP-Echoantwortnachrichten als Antwort auf ICMP-Echoanforderungsnachrichten zu senden. Wenn ein Host nicht mehr auf Pings reagiert, hat dies normalerweise folgende Gründe:

Möglicherweise wurde die Netzwerkverbindung zwischen Ihnen und dem angeforderten Host unterbrochen. Dies kann unzählige Gründe haben: Beschädigung der Kabel, Rauschen bei drahtlosen Verbindungen, defekte Routentabellen, DDoS-Angriffe, problematische Router / Switches dazwischen usw. In diesem Fall können Sie mit der Fehlerbehebung beginnen mit ethtool(8), iwconfig(8), route(8), ping(8)seine Router, tcpdump(8)usw. auf Ziel - Host.
Die Firewall-Einstellung auf dem Zielhost (oder einem Router / einer Firewall zwischen Ihnen und dem Zielhost) kann die Anzahl der Pings (oder den Datenverkehr) begrenzen. Es könnte auch an Tools liegen, wie z. B. fail2ban(8)Firewall- Tools bei Bedarf. Siehe iptables(8)zu überprüfen.
Auf dem Zielhost ist ein Software- / Hardwarefehler aufgetreten. Das Netzwerk-Kernel-Modul auf dem Ziel-Host ist möglicherweise überlastet und / oder verwirrt, oder sogar der gesamte Kernel ist möglicherweise überlastet. Sie sehen Meldungen über at in dmesg(8)auf dem Zielhost oder als Bildschirmausgabe auf der physischen Konsole (wenn der physische Zugriff nicht möglich ist, kann ein anderer Computer mit serieller Konsole Abhilfe schaffen.) Wenn das Problem in Kernel-OOPS / PANIC besteht, kann es sein, dass ein neuerer Kernel mit besseren Treibern verwendet wird Hilfe, oder Sie könnten die Systemabstürze mit Hilfstreibern umgehen watchdog(8). Oder Sie können Hardware-Teile ändern.

— Matija Nalis
quelle

Für Interessierte ist hier der relevante Kernel-Code für die Bearbeitung von ICMP-Echo-Anfragen.

— Ruslan

Erwähnen Sie auch sehr hohe Last (speziell CPU)

— Guilherme Bernal

@GuilhermeBernal Nein, selbst eine extrem hohe CPU-Benutzerlast (in Tausenden) führt nicht zu ICMP-Verlusten (da sie im Kernel bereitgestellt werden, bevor Benutzerprozesse ausgeführt werden können). Eine extrem hohe Netzwerk-PPS-Rate in Kombination mit Low-End-Hardware kann zu Paketverlusten führen, aber solche DDoS fallen unter die Kategorie "Netzwerkkonnektivität"

— Matija Nalis