Jenkins Windows esclave lien qui se termine, avec java.nio.les canaux.ClosedChannelException

Lors de la connexion à windows de la machine en tant qu'esclave, je suis d'erreur suivant je pense que son réseau question connexe, mais ont besoin de l'aide par où commencer à chercher ou ce qui est une solution possible pour cela.

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\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

Ci-dessus mentionné trace de la pile est de salve (Windows) de la machine et de mon Jenkins/Master est en cours d'exécution sur RHEL, je suis en mesure de voir la suite de stacktrace 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)

Avez-vous vérifié l'esclave pot est en cours d'exécution avec succès sur une machine windows
esclave pot est en cours d'exécution avec succès, comme j'essaie de le lancer slave.jar sur l'esclave de la machine, je suis capable de voir l'esclave tente de se connecter à maître, et s'arrête au-dessus mentionnés trace de la pile et de java.nio.les canaux.ClosedChannelException
Avez-vous utilisé le port fixe ou aléatoire JNLP port dans jenkins??
fixe 9001.., je pense que ça peut-être un problème de ports et de sécurité, mais je ne sais pas par où commencer à chercher à partir de!
Le redémarrage de mon serveur jenkins à résoudre ce problème.

OriginalL'auteur yug | 2017-08-01

7
- J'ai observé la même erreur après notre jenkins master a été mis à jour. Il est probable en raison d'une incompatibilité entre Java 7 (v80) et la dernière version de Java 8.
- Vérifier la version de java utilisée par votre maître, et la version java de votre esclave.
- Dans mon cas, je suis en cours d'exécution swarm-client-2.0-jar-with-dependencies.jar sur un hôte linux, et c'est à l'aide de Java 7.
  
  java version "1.7.0_80" Java(TM) SE Runtime Environment (build
  1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, en mode mixte)
- Notre jenkins master a été mis à jour et est maintenant en cours d'exécution Java 8
  
  java version "1.8.0_121" Java(TM) SE Runtime Environment (build
  1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, en mode mixte)
- Lorsque le java sur l'esclave a été mis à jour pour Java 8, les problèmes de connexion disparu.
* À noter que Java 7 n'est plus recevant du public mises à jour: java.com/en/download/faq/java_7.xml
Oui résolu avec JAVA8.. Bravo..:)
Le sujet de cette question est sur le esclave de l'agent, mais voici quelques infos utiles concernant maven java exigences entre l'esclave et le maître: wiki.jenkins.io/affichage/JENKINS/Maven+Projet+Plugin dans Maven emplois et versions de Java compatibilité de la section.

OriginalL'auteur mb-texas
11

Je vivais une erreur similaire que l'OP où la connexion à mon esclave était à la baisse. La cause racine du problème n'était pas dû à une incompatibilité de versions de Java entre Jenkins d'esclave et de maître des hôtes.

Solution
Si vous exécutez Jenkins dans une instance EC2 sur AWS derrière un Elastic Load Balancer (ELB), d'augmenter le "délai d'inactivité de" valeur sous les "attributs" de la section à partir de la valeur par défaut de 60 secondes. J'ai mis la nouvelle valeur de 600 et n'a plus rencontré l'erreur.

Il semble que si une seule commande dans votre processus de création prend plus de 60 secondes sans la sortie du journal, la ELB va mettre fin à la session en raison de l'inactivité de l'activité.

Source: https://issues.jenkins-ci.org/browse/JENKINS-44001?focusedCommentId=312412&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-312412

C'est exactement ce que mon problème a été. Merci!
Merci, j'utilise AWS avec un classique ELB et eu exactement ce problème.
J'ai Jenkins derrière AWS ELB, cela a résolu mon problème!

OriginalL'auteur njtman
3

en plus du journal d'erreur dans le post, j'ai eu aussi le journal des erreurs sous le jenkins répertoire dans 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 arguments invalides: [#####################################,
my_slave_name, -workDir, c:\jenkins, -internalDir, l'accès à distance, -url,
http://jenkins.domain.com/, -sans tête, -jar-cache,
C:\Users\Administrateur.jenkins\cache\jars] le Plus probable d'un
erreur de configuration dans le master "-workDir" n'est pas une option valide

ma solution:

1)windows esclave niveau: près la services de la console de l'interface graphique pour tous les utilisateurs, cela est faut. depuis quelque raison que Microsoft est le verrouillage de l'installation/suppression de windows services

2)windows esclave niveau: tuer tous java et jenkins-esclave processus (s'il existe)

3)windows esclave niveau: supprimer la jenkins esclave de service (s'il existe) cmd: sc delete jenkinsslave-c__jenkins /force (dans mon cas)

4)windows esclave niveau: vérifiez que vous avez java 8 installé: je suis en utilisant jdk1.8.0_151 . désinstaller tous vieux version de java

5)jenkins master niveau de l'interface utilisateur: Changer la façon dont le Jenkins est de se connecter à l'esclave, en vertu de l'esclave configure --> méthode de Lancement: Let Jenkins control this Windows slave as a Windows service (au lieu de Launch agent via Java Web Start)

6) aws niveau: Augmentation la aws elb délai d'Inactivité à 600 (à partir de 60) - comme @njtman suggéré

7)jenkins master niveau de l'interface utilisateur: relancer la agent dans jenkins et attendez quelques minutes.

mon environnement:

jenkins: 2.89.2 , os: windows 2012 R2, java: jdk1.8.0_151

OriginalL'auteur dsaydon
2

J'ai connu le même problème. J'ai découvert que windows esclave basculé en mode "sommeil" spécialement si vos travaux ne sont pas en cours d'exécution à l'encontre d'une interface graphique.
- Pour windows... pas de déplacement de la souris ou du clavier signifie qu'aucune activité.
Alors pour réussir à le résoudre. Sur un Windows7 esclaves, voici ce que j'ai fait:
- Panneau de configuration\Matériel et Audio\Options d'Alimentation
- Spectacle supplémentaire plans
- sélectionnez Haute performance
- Panneau de configuration\Matériel et Audio\Options d'Alimentation\Modifier les Paramètres du Plan
- éteindre l'affichage de ne jamais
- Modifier les paramètres d'alimentation avancés -->arrêter le disque dur après 10000 min
Devrait être ok après cette procédure

Cela semble être de travailler pour moi - merci!

OriginalL'auteur Sheeran D
0

Pas le temps de respirer pour la quasi-esclave...

ok, voici comment j'ai résolu mon cas particulier:

J'ai eu quelques VM avec libvirt/quemu cours d'exécution comme des esclaves. Parce que la libvirt-plugin a été à peu fiable pour moi, j'ai commencé à ceux VM sur mon propre. J'ai demandé à mon soi-même: "Pourquoi cette libvirt-plugin a obligatoirement un temps de retard... Impatience...

Donc, si la libvirt-client (esclave) est en train de dire bonjour de jenkins, vous devriez probablement attendre quelques secondes pour laisser ce pauvre gars un peu respirer. Après le démarrage.

L'esclave était un win7 à l'hôte une ubuntu 18.04

OriginalL'auteur Cutton Eye
0

Sur Windows, j'ai reconnu que j'ai besoin d'ajouter l'option "-noCertificateCheck" attribut les arguments de l'jenkins-slave.xml dans le workdir. Nous utilisons un cert à partir d'une PKI interne sur le maître et c'était le moyen le plus facile de travailler autour d'elle (tout avoir 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>
```
Reconnu par l'exécution manuelle de 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
```
OriginalL'auteur Tom
0

Bien... pour moi, il a travaillé à la solution suivante:

marque le nœud temporaires "hors ligne" et de le remettre "en ligne" nouveau

reconnecter

OriginalL'auteur noName_maciek
-1

J'ai été confrontée au même problème , rectifiée à l'aide de la procédure ci-dessous
1. Aller à Jenkins Url -> Gérer Jenkins -> Node -> Votre Noeud ..vous aurez Personnalisé WorkDir chemin permet de dire C:/Jenkins
2. Ouvrir WorkDir Chemin d'accès et de suppression complète remoting répertoire
3. Re-lancement de l'esclave
OriginalL'auteur user2015131

Vous devez vous connecter pour publier un commentaire.

Pas le temps de respirer pour la quasi-esclave...