web-dev-qa-db-ja.com

Jenkins Windowsスレーブ接続がJava.nio.channels.ClosedChannelExceptionで終了する

スレーブとしてWindowsマシンに接続しているときに、ネットワーク関連の問題があると思うエラーが表示されますが、どこから探し始めるのか、この解決策は何ですか?.

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

上記のスタックトレースは、salve(Windows)マシンからのもので、Jenkins/MasterがRHELで実行されているので、次のスタックトレースを見ることができます。

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)
7
yug
  • Jenkinsマスターが更新された後、同じエラーが発生しました。 Java 7(v80)と最新のJava 8。
  • マスタで使用されているJavaバージョン、およびスレーブのJavaバージョン。
  • 私の場合、Linuxホストでswarm-client-2.0-jar-with-dependencies.jarを実行しており、Java 7。

    Javaバージョン "1.7.0_80" Java(TM)SEランタイム環境(ビルド1.7.0_80-b15)Java HotSpot(TM)64ビットサーバーVM (ビルド24.80-b11、混合モード)

  • Jenkinsマスターがアップグレードされ、現在Java 8

    Javaバージョン "1.8.0_121" Java(TM)SEランタイム環境(ビルド1.8.0_121-b13)Java HotSpot(TM)64ビットサーバーVM (ビルド25.121-b13、混合モード)

  • スレーブのJavaがJava 8に更新されたとき、接続の問題はなくなりました。
8
mb-texas

OPと同様のエラーが発生し、スレーブへの接続が切断されていました。この問題の根本的な原因は、Jenkinsスレーブとマスターホスト間のJavaバージョンの不一致によるものではありませんでした。

SolutionElastic Load Balancer(ELB)の背後にあるAWSのEC2インスタンスでJenkinsを実行している場合、「attributes」の下の「idle timeout」値を増やします。デフォルトの60秒からのセクション。新しい値を600に設定すると、エラーは発生しなくなりました。

ビルドプロセスの1つのコマンドがログ出力なしで60秒を超えると、アイドルアクティビティが原因でELBがセッションを終了するようです。

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

12
njtman

投稿のエラーログに加えて、スレーブのjenkinsディレクトリの下にもエラーログがあります(私にとってはC:\ jenkins\jenkins-slave.err.logでした)。

JNLPファイル http://jenkins.domain.com/computer/my_slave_name/slave-agent.jnlp?encrypt=true に無効な引数があります:[############### ########################、my_slave_name、-workDir、c:\ jenkins、-internalDir、remoting、-url、 http:/ /jenkins.domain.com/ 、-headless、-jar-cache、C:\Users\Administrator.jenkins\cache\jars]おそらくマスター「-workDir」の設定エラーは有効なオプションではありません

私の解決策:

1)windows slave level:closeGUIのservicesコンソールすべてのユーザー-これは必須です。何らかの理由で、MicrosoftはWindowsサービスのインストール/削除をロックしています

2)windowsスレーブレベル:すべてのJavaおよびjenkins-slaveプロセスを強制終了(存在する場合)

3)windowsスレーブレベル:deletejenkins slaveサービス(存在する場合) )from cmd:sc delete jenkinsslave-c__jenkins /force(私の場合)

4)windowsスレーブレベル:Java 8がインストールされていることを確認します:jdk1.8.0_151を使用しています。 uninstallalloldJavaバージョン

5)jenkinsマスターuiレベル:Jenkinsがスレーブ構成でスレーブに接続する方法を変更します->起動方法:Let Jenkins control this Windows slave as a Windows serviceLaunch agent via Java Web Startの代わりに)

6)awsレベル:Increasetheaws elb Idle timeoutto 60060から)-@njtmanが提案したように

7)ジェンキンスマスターUIレベル:relaunchジェンキンスのagent数分。

私の環境:

ジェンキンス:2.89.2、OS:Windows 2012 R2、Java:jdk1.8.0_151

5
dsaydon

同じ問題が発生しました。ジョブがGUIに対して実行されていない場合、Windowsスレーブが特別に「スリープ」モードに切り替わることがわかりました。

  • Windowsの場合...マウスまたはキーボードを動かさないということは、アクティビティがないことを意味します。

その後、正常に解決します。 Windows7スレーブで、私がしたことは次のとおりです。

  • コントロールパネル\ハードウェアとサウンド\電源オプション
  • 追加プランを表示
  • 高性能を選択

  • コントロールパネル\ハードウェアとサウンド\電源オプション\プラン設定の編集

  • ディスプレイをオフにしない
  • 高度な電源設定を変更-> 10000分後にハードディスクをオフにする

この手順の後は大丈夫です

4
Sheeran D

まあ...私にとっては、次の解決策が働いた:

ノードを「一時オフライン」としてマークし、再び「オンライン」に戻します

再接続

1
noName_maciek

ser2015131 の提案は、この問題の解決策を見つけるきっかけになりました。

問題

私は説明します私の場合、それは一部の人々のために働くかもしれません:

  1. ずっと前に、スレーブマシンにJenkinsをサービスとしてインストールしました。
  2. I updated Java on the Jenkins' master computer.

そのため、スレーブに保存されているJenkinsサービスのコードは古くなっています

ソリューション

すべてのスレーブマシンで次の手順を実行します。

  1. 更新Javaバージョン。

    Javaバージョンは、マスターコンピューターにインストールされているバージョンと同じか、互換性があります。

  2. 古いスレーブコードを削除します。これは、ノードの構成の下の[リモートルートディレクトリ]フィールドで指定されたフォルダー内にあります。

    すべてのjenkins-slave。*ファイルを削除し、jenkins_agent.pidファイルと「remoting」および「workspace」フォルダーのみを残しました。

  3. WebブラウザーからJenkinsのスレーブノードインターフェイスに移動し、ボタンをクリックします。

    新しいJNLPファイルをダウンロードして、新しい(更新された)Jenkinsサービスをスレーブマシンにインストールします。

  4. ダウンロードしたファイルを実行し、メニューに移動して「サービスとしてインストール」をクリックします。

それが役に立てば幸い!

1
Streiten

Windowsでは、workdirのjenkins-slave.xmlの引数に「-noCertificateCheck」属性を追加する必要があることを認識しました。マスターの内部PKIからの証明書を使用します。これは、これを回避する最も簡単な方法です(すべてが内部ネットワークにあります)。

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

コマンドプロンプトからエージェントを手動で実行することでこれを認識しました。

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
0
Tom

仮想奴隷のために息をする時間はありません...

さて、ここで私は私の特別なケースをどのように解決したか:

Libvirt/quemuがスレーブとして実行されているVMがいくつかありました。 libvirt-pluginは信頼性が低いため、これらのVMを自分で起動しました。私は自分に尋ねました:「なぜこのlibvirt-pluginには必須の遅延時間がありましたか...焦り...

そのため、libvirt-client(スレーブ)がhelloをジェンキンスに言っている場合、この貧しい人が少し息をするのを待つ必要があるでしょう。起動後。

奴隷はwin7で、ホストはubuntu 18.04でした

0
Cutton Eye