スレーブとして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)
私の場合、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、混合モード)
OPと同様のエラーが発生し、スレーブへの接続が切断されていました。この問題の根本的な原因は、Jenkinsスレーブとマスターホスト間のJavaバージョンの不一致によるものではありませんでした。
SolutionElastic Load Balancer(ELB)の背後にあるAWSのEC2インスタンスでJenkinsを実行している場合、「attributes」の下の「idle timeout」値を増やします。デフォルトの60秒からのセクション。新しい値を600に設定すると、エラーは発生しなくなりました。
ビルドプロセスの1つのコマンドがログ出力なしで60秒を超えると、アイドルアクティビティが原因でELBがセッションを終了するようです。
投稿のエラーログに加えて、スレーブの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 service
(Launch agent via Java Web Start
の代わりに)
6)awsレベル:Increasetheaws elb Idle timeoutto 600
(60
から)-@njtmanが提案したように
7)ジェンキンスマスターUIレベル:relaunchジェンキンスのagent数分。
私の環境:
ジェンキンス:2.89.2、OS:Windows 2012 R2、Java:jdk1.8.0_151
同じ問題が発生しました。ジョブがGUIに対して実行されていない場合、Windowsスレーブが特別に「スリープ」モードに切り替わることがわかりました。
その後、正常に解決します。 Windows7スレーブで、私がしたことは次のとおりです。
高性能を選択
コントロールパネル\ハードウェアとサウンド\電源オプション\プラン設定の編集
この手順の後は大丈夫です
まあ...私にとっては、次の解決策が働いた:
ノードを「一時オフライン」としてマークし、再び「オンライン」に戻します
再接続
ser2015131 の提案は、この問題の解決策を見つけるきっかけになりました。
私は説明します私の場合、それは一部の人々のために働くかもしれません:
そのため、スレーブに保存されているJenkinsサービスのコードは古くなっています。
すべてのスレーブマシンで次の手順を実行します。
更新Javaバージョン。
Javaバージョンは、マスターコンピューターにインストールされているバージョンと同じか、互換性があります。
古いスレーブコードを削除します。これは、ノードの構成の下の[リモートルートディレクトリ]フィールドで指定されたフォルダー内にあります。
すべてのjenkins-slave。*ファイルを削除し、jenkins_agent.pidファイルと「remoting」および「workspace」フォルダーのみを残しました。
WebブラウザーからJenkinsのスレーブノードインターフェイスに移動し、ボタンをクリックします。
新しいJNLPファイルをダウンロードして、新しい(更新された)Jenkinsサービスをスレーブマシンにインストールします。
それが役に立てば幸い!
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
さて、ここで私は私の特別なケースをどのように解決したか:
Libvirt/quemuがスレーブとして実行されているVMがいくつかありました。 libvirt-pluginは信頼性が低いため、これらのVMを自分で起動しました。私は自分に尋ねました:「なぜこのlibvirt-pluginには必須の遅延時間がありましたか...焦り...
そのため、libvirt-client(スレーブ)がhelloをジェンキンスに言っている場合、この貧しい人が少し息をするのを待つ必要があるでしょう。起動後。
奴隷はwin7で、ホストはubuntu 18.04でした