Korzystam z serwera Jenkins (2.138.2) z około tuzinem węzłów Mac. Każdy z tych węzłów działa w High Sierra, z wyjątkiem tylko jednego, który obsługuje Mojave.
Mój problem polega na tym, że bardzo sporadycznie (czasami raz dziennie, czasem raz w tygodniu, czasem 3 tygodnie bez problemów, czasem 5 w ciągu dnia), jeden lub więcej z tych węzłów Mac przerywa połączenie z serwerem Jenkins na kilka minut w środek kompilacji, w wyniku czego ślad stosu wygląda następująco:
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)
Może się to zdarzać częściej, ale nie pojawia się, ponieważ nie ma go podczas kompilacji, ale nie mam dowodów na poparcie tego. Wydaje się również, że tak się nie dzieje w węzłach Windows lub Linux.
Co próbowałem:
- Wyłączanie ARP w węzłach Mac, ponieważ istnieją posty datowane na Mavericks, które sugerują istnienie błędu ARP: https://blog.macstadium.com/blog/osx-10-9-mavericks-bugs
- Upewnij się, że wszystkie komputery Mac są podłączone bezpośrednio do przełącznika sieciowego (brak Wi-Fi)
- Upewnij się, że komputery Mac są skonfigurowane tak, aby nigdy nie iść spać
- Sprawdzono dzienniki główne Jenkins pod kątem innych wyjątków, nic ciekawego nie związanego z tym problemem
- Próbowałem odtworzyć ten problem, zwiększając obciążenie procesora, bez zauważalnego wpływu na utratę pakietów
- Verified LaunchAgent działa poprawnie na wszystkich węzłach (nie działają zduplikowane usługi, wszystkie usługi działają w ten sam sposób - klient JNLP)
- Zdałem sobie sprawę, że wiele z tych wyjątków zdarzało się o tej samej porze każdej nocy (01:06), więc sprawdziłem dziennik systemowy na jednym z komputerów Mac, aby znaleźć com.apple.mdworker.shared uruchamiany każdej nocy o 01:06. Czytałem online, że jest uruchomiony indeksator Spotlight Search i że może on powodować „ekstremalne opieszałość” podczas działania. Na razie wyłączyłem wyszukiwanie Spotlight w jednym polu i raportuję wyniki po sprawdzeniu, czy problem się powtórzy.
Objawy:
- Co najmniej 50% utraty pakietów przez około 5 minut na raz
- java.nio.channels.ClosedChannelException and Backing channel „JNLP4-connect connection from ...” Wyjątki
- Przede wszystkim komputery Mac z systemem High Sierra lub Mojave
W razie potrzeby mogę podać więcej informacji, dołożyłem wszelkich starań, aby rozwiązać problem i niektóre z rzeczy, które próbowałem. Każda pomoc jest doceniana, mam nadzieję, że ktoś już to widział. Byłbym również wdzięczny, gdyby ktoś miał pomysły na bardziej uważne monitorowanie tego problemu w sposób zautomatyzowany.
Aktualizacje
Skonfigurowałem monitorowanie danych węzłów za pośrednictwem Grafana, aby śledzić zużycie procesora i pamięci, a także bajty sieciowe wysyłane i odbierane. Skonfigurowałem także serwer Xymon, aby upewnić się, że węzły są osiągalne przez ping i wysłać alert, jeśli coś będzie niedostępne przez ~ 10 minut.
Incydent powtórzył się dwa razy w tym tygodniu, szczególnie na jednym komputerze Mac (ciekawie działającym Mojave). Grafana nie wykazała niczego nienormalnego w procesorze, pamięci ani we / w sieci, jednak Xymon poinformował, że węzeł nie reagował na ping w momencie incydentu. Więc pudełko nie robiło nic, ale nie reagowało na ping przez co najmniej 10 minut i dlatego spowodowało błąd kompilacji.
Więcej aktualizacji
Miałem dzisiaj 5 węzłów offline w tym samym czasie (~ 10: 34am), a pliki install.log są wypełnione następującymi komunikatami:
<date> <hostname> deleted[443]: diskmanagement: [DMManager(PrivateMethods) clientConforms:error:]: currentThread=15975=0x3e67 expectedThread=8195=0x2003
Czy ktoś wie, czym jest ten usunięty demon i co może próbować zrobić? Naprawdę nie wiem, co może zabić agenta Jenkinsa na tych węzłach Mac jednocześnie. Może jakiś restart Java lub exit Java () uruchamiany w ramach procesu czyszczenia?
Należy zauważyć, że wiele węzłów to kopie zapasowe wehikułu czasu jednego węzła, więc problem jest prawdopodobnie taki sam we wszystkich z nich.