[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin commented on JENKINS-59910 Re: Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread Thanks! I'll give it a shot. For future readers of this ticket Jesse referenced to WebSocket mode introduced in 2.217 https://www.jenkins.io/blog/2020/02/02/web-socket/ Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202661.1571866437000.17651.1587767520231%40Atlassian.JIRA.
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title
Andrey Babushkin updated an issue
Jenkins / JENKINS-59910
Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Change By:
Andrey Babushkin
Investigating a spike in builds queue size we've found out that TcpSlaveAgent listener thread was dead with the following logs:{code:java}2019-10-23 09:02:17.236+ [id=200815]SEVERE h.TcpSlaveAgentListener$ConnectionHandler#lambda$new$0: Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread[TCP agent connection handler #1715 with /10.125.100.99:47700,5,main]java.lang.UnsupportedOperationException: Network layer is not supposed to call isSendOpenat org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:730)at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340)at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:738)at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340)at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.isSendOpen(SSLEngineFilterLayer.java:237)at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:738)at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340)at org.jenkinsci.remoting.protocol.impl.ConnectionHeadersFilterLayer.isSendOpen(ConnectionHeadersFilterLayer.java:514)at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.doSend(ProtocolStack.java:690)at org.jenkinsci.remoting.protocol.ApplicationLayer.write(ApplicationLayer.java:157)at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.start(ChannelApplicationLayer.java:230)at org.jenkinsci.remoting.protocol.ProtocolStack.init(ProtocolStack.java:201)at org.jenkinsci.remoting.protocol.ProtocolStack.access$700(ProtocolStack.java:106)at org.jenkinsci.remoting.protocol.ProtocolStack$Builder.build(ProtocolStack.java:554)at org.jenkinsci.remoting.engine.JnlpProtocol4Handler.handle(JnlpProtocol4Handler.java:153)at jenkins.slaves.JnlpSlaveAgentProtocol4.handle(JnlpSlaveAgentProtocol4.java:203)at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListener.java:271)2019-10-23 09:02:17.237+ [id=200815]WARNING hudson.TcpSlaveAgentListener$1#run: Connection handler failed, restarting listenerjava.lang.UnsupportedOperationException: Network layer is not supposed to call isSendOpenat org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:730)at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340)at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:738)at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340)at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.isSendOpen(SSLEngineFilterLayer.java:237)at org.jenkinsci.remot
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin updated an issue Jenkins / JENKINS-59910 Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread Change By: Andrey Babushkin Environment: Official Docker image based on jenkins/jenkins:2. 190 204 . 1 5 -jdk11Both with and without Nginx 1.17.6 as reverse proxyUbuntu 18.04 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202661.1571866437000.16805.1587682260312%40Atlassian.JIRA.
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin updated an issue Jenkins / JENKINS-59910 Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread Change By: Andrey Babushkin Environment: Official Docker image jenkins/jenkins:2.190.1-jdk11 No HTTPS enabled Both with and without Nginx 1.17.6 as reverse proxy Ubuntu 18.04 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202661.1571866437000.16804.1587682260297%40Atlassian.JIRA.
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin commented on JENKINS-59910 Re: Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread Nope it DID occur and still occur sometimes, we on Jenkins 2.204.5 now. Jesse Glick could you please give me some hints of how to debug this further to find the root cause? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202661.1571866437000.16808.1587682260378%40Atlassian.JIRA.
[JIRA] (JENKINS-55287) Pipeline: Failure to load flow node: FlowNode was not found in storage for head
Title: Message Title Andrey Babushkin commented on JENKINS-55287 Re: Pipeline: Failure to load flow node: FlowNode was not found in storage for head I think this is happening due to our pipeline durability settings override - we've set it to MAX_PERFORMANCE. Therefore all pipelines die when Jenkins master dies Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.196374.1545361815000.5797.1574540760603%40Atlassian.JIRA.
[JIRA] (JENKINS-49707) Auto retry for elastic agents after channel closure
Title: Message Title Andrey Babushkin commented on JENKINS-49707 Re: Auto retry for elastic agents after channel closure We use kubernetes plugin with our bare-metal kubernetes cluster and the problem is that pipeline can run indefinitely if agent inside pod were killed/underlying node was restarted. Is there any option to tweak such behavior, e.g. some timeout settings (except explicit timeout step)? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.188646.1519349293000.3530.1574169602160%40Atlassian.JIRA.
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin commented on JENKINS-59910 Re: Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread It didn't occur after rollback to Jenkins 2.176.4 Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202661.1571866437000.4171.1572349440104%40Atlassian.JIRA.
[JIRA] (JENKINS-59910) Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread
Title: Message Title Andrey Babushkin created an issue Jenkins / JENKINS-59910 Nodes can't connect to master after Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread Issue Type: Bug Assignee: Unassigned Components: core, kubernetes-plugin Created: 2019-10-23 21:33 Environment: Official Docker image jenkins/jenkins:2.190.1-jdk11 No HTTPS enabled Ubuntu 18.04 Priority: Critical Reporter: Andrey Babushkin Investigating a spike in builds queue size we've found out that TcpSlaveAgent listener thread was dead with the following logs: 2019-10-23 09:02:17.236+ [id=200815]SEVERE h.TcpSlaveAgentListener$ConnectionHandler#lambda$new$0: Uncaught exception in TcpSlaveAgentListener ConnectionHandler Thread[TCP agent connection handler #1715 with /10.125.100.99:47700,5,main] java.lang.UnsupportedOperationException: Network layer is not supposed to call isSendOpen at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:730) at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340) at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:738) at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340) at org.jenkinsci.remoting.protocol.impl.SSLEngineFilterLayer.isSendOpen(SSLEngineFilterLayer.java:237) at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.isSendOpen(ProtocolStack.java:738) at org.jenkinsci.remoting.protocol.FilterLayer.isSendOpen(FilterLayer.java:340) at org.jenkinsci.remoting.protocol.impl.Connect
[JIRA] (JENKINS-58685) Please login to acess job XXX
Title: Message Title Andrey Babushkin commented on JENKINS-58685 Re: Please login to acess job XXX I've found this ticket during my investigation of the following messages in Jenkins log: o.e.j.s.h.ContextHandler$Context#log: While serving http://openvino-ci.intel.com/job/private-ci/job/ie/job/build-windows/2162/yabv/buildFlow: org.acegisecurity.AccessDeniedException: Please login to access job private-ci We're using matrix authorization and Job-Read permission wasn't checked for Anonymous role - when I checked it messages have gone. But what if we still want to restrict read access for anonymous users? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200968.1564173978000.10921.1571486160205%40Atlassian.JIRA.
[JIRA] (JENKINS-43038) Intermittent error "Cannot contact node123: java.lang.InterruptedException " in jenkins
Title: Message Title Andrey Babushkin commented on JENKINS-43038 Re: Intermittent error "Cannot contact node123: java.lang.InterruptedException " in jenkins We're experiencing the same issue when our java agent get killed my OOM or machine on which agent is running is rebooted. Is there any way to reduce amount of time Jenkins will wait till the build will be mark as failed? Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.180142.1490197006000.10792.1571432400995%40Atlassian.JIRA.
[JIRA] (JENKINS-55287) Pipeline: Failure to load flow node: FlowNode was not found in storage for head
Title: Message Title Andrey Babushkin commented on JENKINS-55287 Re: Pipeline: Failure to load flow node: FlowNode was not found in storage for head We've faced this issue today. Our 300+ parallel pipeline builds have failed simultaneously due to the error in ticket's description. But I've found the following in Jenkins server's logs in the same time: [207043.805s][warning][os,thread] Attempt to protect stack guard pages failed (0x7f6d188c9000-0x7f6d188cd000). [207043.805s][warning][os,thread] Attempt to deallocate stack guard pages failed. OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x7f6d187c8000, 16384, 0) failed; error='Not enough space' (errno=12) [207043.810s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. [207043.811s][warning][os,thread] Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 16384 bytes for committing reserved memory. # An error report file with more information is saved as: # /tmp/hs_err_pid6.log So I guess something is wrong with our settings (out of memory on server with 180GB of RAM? Our Jenkins instance's load isn't that much, we've run the same load on VM with 60GB of RAM, but with 20 GB of swap) Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Andrey Babushkin commented on JENKINS-53752 Re: Block PRs from forks from untrusted users I'm sorry Brian J Murrell, It seems I've just screwed the config of my GitHub Organization folder. I've set "Build strategies" like on the picture you've provided and "Trust" to "Nobody". Jenkins creates jobs for PRs opened by untrusted persons, but doesn't run them. That's exactly what I've needed, thank you Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194259.1537809356000.3618.1565890320370%40Atlassian.JIRA.
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Andrey Babushkin commented on JENKINS-53752 Re: Block PRs from forks from untrusted users Brian J Murrell, no, it isn't because it blocks only Jenkinsfile changes (it will be taken from PR's target branch, not source) and still executes it. Therefore any user who can open a PR in your repository can easily modify build scripts/CMake files and gain access to your build systems Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194259.1537809356000.3558.1565887320277%40Atlassian.JIRA.
[JIRA] (JENKINS-38877) Build History by Node doesn't work with Pipeline
Title: Message Title Andrey Babushkin commented on JENKINS-38877 Re: Build History by Node doesn't work with Pipeline Jesse Glick, are there any alternative ways to find out what builds were scheduled on a node? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175287.1476142592000.0.1559766120511%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command
Title: Message Title
Andrey Babushkin edited a comment on JENKINS-45228
Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command
I have the same situation [~viviendelmon] has.[~whitty] it seems that the only workaround is to add direct 'sh' steps with direct 'git' invocation as [~asmorkalov] suggested here :{code:java}sshagent(credentials: [account]) { sh "git clone ${repo_url} ." sh "git lfs install" sh "git checkout ${source_branch}" sh "git checkout ${target_branch}" sh "git merge --no-ff ${source_branch}" sh "git submodule update --init --recursive" sh "git lfs pull"}{code}
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-45228) Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command
Title: Message Title Andrey Babushkin commented on JENKINS-45228 Re: Git merge requires authentication in LFS merges, plugin does not authenticate the git merge command I have the same situation Vivien Delmon has. Greg Whiteley it seems that the only workaround is to add direct 'sh' steps with direct 'git' invocation as Alexander Smorkalov suggested here Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55819) Jenkins occasionally loses parameters passed downstream
Title: Message Title
Andrey Babushkin created an issue
Jenkins / JENKINS-55819
Jenkins occasionally loses parameters passed downstream
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2019-01-28 18:06
Environment:
Jenkins LTS 2.138 deployed from official Docker image pipeline-build-step 2.7 pipeline-model-api 1.2.7 pipeline-model-declarative-agent 1.1.1 pipeline-model-definition 1.2.7 pipeline-model-extensions 1.2.7
Priority:
Minor
Reporter:
Andrey Babushkin
We use pipeline jobs retrieved via Git SCM. There are simplified version of how they look like:
// name: my_upstream_job.groovy
// just triggers some downstream build
thebuild = build job: 'my_downstream_job',
propagate: false,
parameters: [
string(name: "my_str_param", value: "foo")
]
// name: my_downstream_job.groovy
// occasionally fails due to java.lang.NullPointerException: Cannot invoke method contains() on null object
properties([
parameters([
string(
defaultValue: '',
description: 'Some parameter for demo',
name: 'my_str_param')
])
])
// if we're using something like this outside of node() step
// build can occasionally fail
if (env.my_str_param.contains("foo")) {
println 'Called
[JIRA] (JENKINS-3509) Parametrized build should allow mandatory parameters
Title: Message Title Andrey Babushkin commented on JENKINS-3509 Re: Parametrized build should allow mandatory parameters It'll be great to have some parameter for this like 'trim: true' in Pipeline (this issue JENKINS-47115). 'mandatory: true' looks good enough. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
