La connexion esclave Jenkins Windows est à la base de Java.nio.channels.ClosedChannelException
Lors de la connexion à la machine Windows en tant qu'esclave, je reçois l'erreur suivante. Je pense que c'est un problème lié au réseau, mais j'ai besoin d'aide pour savoir où commencer ou quelle solution est envisageable.
INFO: Terminated
Aug 01, 2017 10:15:54 PM hudson.remoting.JarCacheSupport$1 run
WARNING: Failed to resolve a jar 06bcb4519543f5ec83cf9d6da9f6cfbe
Java.io.IOException: Failed to write to C:\Users\Administrator\.jenkins\cache\jars\06\BCB4519543F5EC83CF9D6DA9F6CFBE.jar
at hudson.remoting.FileSystemJarCache.retrieve(FileSystemJarCache.Java:133)
at hudson.remoting.JarCacheSupport$1.run(JarCacheSupport.Java:64)
at Java.util.concurrent.Executors$RunnableAdapter.call(Executors.Java:483)
at Java.util.concurrent.FutureTask.run(FutureTask.Java:274)
at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.Java:110)
at Java.lang.Thread.run(Thread.Java:809)
Caused by: Java.io.IOException: Backing channel 'JNLP4-connect connection to dr2r4m1p21/172.20.238.41:9001' is disconnected.
at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.Java:192)
at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.Java:257)
at com.Sun.proxy.$Proxy4.writeJarTo(Unknown Source)
at hudson.remoting.FileSystemJarCache.retrieve(FileSystemJarCache.Java:98)
... 5 more
Caused by: Java.nio.channels.ClosedChannelException
at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.Java:208)
at org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.Java:222)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.Java:832)
at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.Java:287)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.Java:181)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.switchToNoSecure(SSLEngineFilterLayer.Java:283)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processWrite(SSLEngineFilterLayer.Java:503)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processQueuedWrites(SSLEngineFilterLayer.Java:248)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doSend(SSLEngineFilterLayer.Java:200)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.Java:166)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.Java:832)
at org.jenkinsci.remoting.protocol.NetworkLayer.onRecvClosed(NetworkLayer.Java:154)
at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer.access$1500(BIONetworkLayer.Java:48)
at org.jenkinsci.remoting.protocol.impl.BIONetworkLayer$Reader.run(BIONetworkLayer.Java:247)
at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1157)
at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:627)
at hudson.remoting.Engine$1$1.run(Engine.Java:94)
... 1 more
La trace de pile mentionnée ci-dessus provient d'une machine sous Windows (Windows) et mon Jenkins/Master s'exécute sur RHEL. Je suis en mesure de voir la pile suivante, là.
INFO: Accepted JNLP4-connect connection #113 from /172.20.238.31:60363
Aug 01, 2017 12:45:55 PM jenkins.slaves.DefaultJnlpSlaveReceiver channelClosed
WARNING: Computer.threadPoolForRemoting [#42] for Build_Agent terminated
Java.nio.channels.ClosedChannelException
at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.Java:208)
at org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.Java:222)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.Java:832)
at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.Java:287)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.onRecvClosed(SSLEngineFilterLayer.Java:181)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.switchToNoSecure(SSLEngineFilterLayer.Java:283)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processWrite(SSLEngineFilterLayer.Java:503)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.processQueuedWrites(SSLEngineFilterLayer.Java:248)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doSend(SSLEngineFilterLayer.Java:200)
at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.doCloseSend(SSLEngineFilterLayer.Java:213)
at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.doCloseSend(ProtocolStack.Java:800)
at org.jenkinsci.remoting.protocol.ApplicationLayer.doCloseWrite(ApplicationLayer.Java:173)
at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer$ByteBufferCommandTransport.closeWrite(ChannelApplicationLayer.Java:311)
at hudson.remoting.Channel.close(Channel.Java:1295)
at hudson.remoting.Channel.close(Channel.Java:1263)
at jenkins.slaves.DefaultJnlpSlaveReceiver.afterChannel(DefaultJnlpSlaveReceiver.Java:173)
at org.jenkinsci.remoting.engine.JnlpConnectionState$4.invoke(JnlpConnectionState.Java:421)
at org.jenkinsci.remoting.engine.JnlpConnectionState.fire(JnlpConnectionState.Java:312)
at org.jenkinsci.remoting.engine.JnlpConnectionState.fireAfterChannel(JnlpConnectionState.Java:418)
at org.jenkinsci.remoting.engine.JnlpProtocol4Handler$Handler$1.run(JnlpProtocol4Handler.Java:334)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.Java:28)
at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1142)
at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:617)
at Java.lang.Thread.run(Thread.Java:745)
- J'ai observé la même erreur après la mise à jour de notre maître Jenkins. Cela est probablement dû à une incompatibilité entre Java 7 (v80) et la dernière version de Java 8.
- Vérifiez la version Java utilisée par votre maître et la version Java de votre esclave.
Dans mon cas, j'utilise swarm-client-2.0-jar-with-dependencies.jar sur un hôte Linux, qui utilisait Java 7.
Java version "1.7.0_80" Environnement d'exécution SE Java (TM) (build 1.7.0_80-b15) Serveur 64 bits Java HotSpot (TM) VM (build 24.80-b11, mode mixte)
Notre maître jenkins a été mis à niveau et exécute maintenant Java 8
Version Java "1.8.0_121" Environnement d'exécution SE Java (TM) (build 1.8.0_121-b13) Serveur 64 bits Java HotSpot (TM) VM (build 25.121-b13, mode mixte)
- Lorsque le Java sur l'esclave a été mis à jour vers Java 8, les problèmes de connexion ont disparu.
J'éprouvais une erreur similaire à celle de l'OP où la connexion à mon esclave était interrompue. La cause première du problème n'était pas due à une incompatibilité dans les versions Java entre les hôtes esclaves et maîtres Jenkins.
Solution Si vous exécutez Jenkins dans une instance EC2 sur AWS derrière un Elastic Load Balancer (ELB), augmentez la valeur du "délai d'inactivité" dans la section "attributs" à partir de la valeur par défaut de 60 secondes. J'ai mis la nouvelle valeur à 600 et je n'ai plus rencontré l'erreur.
Il semble que si une seule commande de votre processus de construction dure plus de 60 secondes sans sortie de journal, le ELB mettra fin à la session en raison d’une activité inactive.
en plus du journal des erreurs dans l'article, j'ai aussi le journal des erreurs dans le répertoire jenkins de l'esclave (pour moi, c'était C:\jenkins\jenkins-slave.err.log):
Fichier JNLP http://jenkins.domain.com/computer/my_slave_name/slave-agent.jnlp?encrypt=true a des arguments non valides: [######################################, my_slave_name, -workDir, c:\jenkins, -internalDir, remoting, -url, http://jenkins.domain.com/ , -headless, -jar-cache, C:\Utilisateurs\Administrateur.jenkins\cache\jars] Probablement un erreur de configuration dans le maître "-workDir" n'est pas une option valide
ma solution:
1) Windows niveau esclave: fermer la services console dans l'interface graphique pour tous les utilisateurs - c'est un must. pour une raison quelconque, Microsoft verrouille l'installation/la suppression de services Windows
2) Niveau esclave Windows: éliminez tous les processus Java et jenkins-slave (s'ils existent).
3) Windows niveau esclave: supprimer le esclave Jenkins service (s'il existe) de cmd: sc delete jenkinsslave-c__jenkins /force (dans mon cas)
4) Niveau esclave Windows: vérifiez que vous avez installé Java 8: j'utilise jdk1.8.0_151. désinstaller tous ancien version Java
5) Niveau de l'interface utilisateur principale de Jenkins: Modifie la façon dont Jenkins est connecté à l'esclave sous Configuration esclave -> Méthode de lancement: Let Jenkins control this Windows slave as a Windows service (au lieu de Launch agent via Java Web Start).
6) Niveau aws: augmentation le délai d'inactivité de l'ELS elb à 600 (à partir de 60) - comme l'a suggéré @njtman
7) jenkins master ui level: relance le agent dans jenkins et attendez plusieurs minutes.
mon environnement:
jenkins: 2.89.2, os: Windows 2012 R2, Java: jdk1.8.0_151
J'ai vécu le même problème. J'ai découvert que l'esclave Windows passait en mode "veille" spécialement si vos tâches ne fonctionnaient pas avec une interface graphique.
- Pour les fenêtres ... aucun mouvement de la souris ou du clavier ne signifie aucune activité.
Puis résoudre avec succès. Sur un esclave Windows7, voici ce que j'ai fait:
- Panneau de configuration\Matériel et audio\Options d'alimentation
- Afficher les plans supplémentaires
sélectionnez Haute performance
Panneau de configuration\Matériel et audio\Options d'alimentation\Modifier les paramètres du plan
- éteindre jamais l'affichage
- Modifier les paramètres d'alimentation avancés -> éteindre le disque dur après 10000 min
Devrait être ok après cette procédure
Sous Windows, j'ai reconnu que je devais ajouter l'attribut "-noCertificateCheck" aux arguments du fichier jenkins-slave.xml dans le répertoire de travail. Nous utilisons un certificat d'une infrastructure à clé publique interne sur le maître et c'était la manière la plus simple de le contourner (avoir tout dans le réseau interne).
<arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl https://jenkins.ourdomain.com/computer/Windows%20build%20server%20-%20Bare%20metal/slave-agent.jnlp -secret abc -noCertificateCheck</arguments>
J'ai reconnu cela en exécutant manuellement l'agent à partir de l'invite de commande:
Java -jar agent.jar -jnlpUrl https://jenkins.ourdomain.com/computer/Windows%20build%20server%20-%20Bare%20metal/slave-agent.jnlp -secret abc -workDir "D:\agentroot" -noCertificateCheck
Eh bien ... pour moi cela a fonctionné la solution suivante:
marquer le noeud "hors ligne temporaire" et le remettre "en ligne" à nouveau
reconnecter
Pas le temps de souffler pour un esclave virtuel ...
ok, voici comment j'ai résolu mon cas spécial:
J'ai eu des VM avec libvirt/quemu s'exécutant en tant qu'esclaves. Parce que libvirt-plugin était trop peu fiable pour moi, j'ai démarré ces VMs tout seul. Je me suis demandé: "Pourquoi ce plugin libvirt avait un délai obligatoire ... Impatience ...
Donc, si le client libvirt (esclave) dit bonjour à Jenkins, vous devriez probablement attendre quelques secondes pour laisser ce pauvre gars respirer un peu. Après avoir démarré.
L'esclave était un Win7 l'hôte un Ubuntu 18.04