Überwachen Sie die Netzwerkaktivität auf dem Mac für java.nio.channels.ClosedChannelException

Ich verwende einen Jenkins-Server (2.138.2) mit etwa einem Dutzend Mac-Knoten. Jeder dieser Knoten führt High Sierra aus, mit Ausnahme von nur einem, der Mojave ausführt.

Mein Problem ist, dass sehr oft (manchmal einmal pro Tag, manchmal einmal pro Woche, manchmal 3 Wochen ohne Probleme, manchmal 5 pro Tag) ein oder mehrere dieser Mac-Knoten ihre Verbindung für einige Minuten vom Jenkins-Server trennen in der Mitte eines Builds, was zu einer Stapelverfolgung wie folgt führt:

 FATAL: command execution failed 01:24:49 java.nio.channels.ClosedChannelException 01:24:49 at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.java:154) 01:24:49 at org.jenkinsci.remoting.protocol.impl.NIONetworkLayer.ready(NIONetworkLayer.java:179) 01:24:49 at org.jenkinsci.remoting.protocol.IOHub$OnReady.run(IOHub.java:795) 01:24:49 at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) 01:24:49 at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59) 01:24:49 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 01:24:49 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 01:24:49 at java.lang.Thread.run(Thread.java:748) 01:24:49 Caused: java.io.IOException: Backing channel 'JNLP4-connect connection from X.X.X.X/X.X.X.X:52164' is disconnected. 01:24:49 at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:214) 01:24:49 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:283) 01:24:49 at com.sun.proxy.$Proxy108.isAlive(Unknown Source) 01:24:49 at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:1143) 01:24:49 at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:1135) 01:24:49 at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:155) 01:24:49 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:109) 01:24:49 at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) 01:24:49 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 01:24:49 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) 01:24:49 at hudson.model.Build$BuildExecution.build(Build.java:206) 01:24:49 at hudson.model.Build$BuildExecution.doRun(Build.java:163) 01:24:49 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:504) 01:24:49 at hudson.model.Run.execute(Run.java:1819) 01:24:49 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 01:24:49 at hudson.model.ResourceController.execute(ResourceController.java:97) 01:24:49 at hudson.model.Executor.run(Executor.java:429) 

Es könnte häufiger vorkommen, aber es wird nicht angezeigt, weil es nicht während eines Builds ist, aber ich habe keine Beweise, die dies unterstützen. Es scheint auch nicht auf Windows- oder Linux-Knoten zu passieren.

Was ich versucht habe:

• Deaktivieren von ARP auf den Mac-Knoten, da es Beiträge gibt, die auf Mavericks zurückgehen, was auf einen ARP-Fehler hinweist: https://blog.macstadium.com/blog/osx-10-9-mavericks-bugs
• Stellen Sie sicher, dass alle Macs direkt an den Netzwerk-Switch angeschlossen sind (kein WLAN)
• Stellen Sie sicher, dass Macs so konfiguriert sind, dass sie niemals in den Ruhezustand gehen
• Geprüfte Jenkins Master-Protokolle auf andere Ausnahmen, nichts Interessantes in Bezug auf dieses Problem
• Es wurde versucht, dieses Problem durch Anheben der CPU-Last zu reproduzieren, keine spürbaren Auswirkungen auf den Paketverlust
• Der verifizierte LaunchAgent ist auf allen Knoten korrekt (es werden keine doppelten Dienste ausgeführt, alle Dienste laufen auf dieselbe Weise - JNLP-Client).
• Ich stellte fest, dass viele dieser Ausnahmen jede Nacht (01:06 Uhr morgens) zur gleichen Zeit stattfanden. Daher überprüfte ich das Systemprotokoll auf einem der Macs, um zu sehen, dass com.apple.mdworker.shared jede Nacht um 1:06 Uhr ausgeführt wird. Ich habe online gelesen, dass dies der Spotlight Search-Indexer ist, der ausgeführt wird und zu extremer Trägheit führen kann. Ich habe die Spotlight-Suche vorerst für ein Feld deaktiviert und erstelle die Ergebnisse, wenn das Problem erneut auftritt.

Symptome:

• Mindestens 50% Paketverlust für jeweils etwa 5 Minuten
• java.nio.channels.ClosedChannelException und Backing-Kanal 'JNLP4-Verbindungsverbindung von ...' Ausnahmen
• Hauptsächlich Mac-Boxen mit High Sierra oder Mojave

Ich kann bei Bedarf mehr Informationen zur Verfügung stellen, ich habe mein Bestes getan, um das Problem und einige der Dinge, die ich ausprobiert habe, darzulegen. Jede Hilfe wird geschätzt, hoffentlich hat dies jemand schon gesehen. Ich würde mich auch freuen, wenn jemand Ideen hat, wie man dies automatisiert genauer überwachen kann.

Aktualisierung

Ich habe die Überwachung der betreffenden Knoten durch Grafana eingerichtet, um die CPU- und Speichernutzung sowie die gesendeten und empfangenen Netzwerkbytes zu verfolgen. Ich habe auch einen Xymon-Server eingerichtet, um sicherzustellen, dass die Knoten per Ping erreichbar sind, und um eine Warnung zu senden, wenn ~ 10 Minuten lang nichts verfügbar ist.

Der Vorfall wiederholte sich diese Woche zweimal auf einem Mac (interessanterweise läuft Mojave). Grafana zeigte nichts Ungewöhnliches bei CPU, Arbeitsspeicher oder Netzwerk-E / A, jedoch gab Xymon an, dass der Knoten zum Zeitpunkt des Vorfalls nicht auf Ping reagierte. Die Box machte also nichts, aber sie reagierte mindestens 10 Minuten lang nicht auf Ping und verursachte daher einen Fehler beim Build.