[JIRA] (JENKINS-38807) Jenkins 2.7.4 seems to leave behind Java processes (on Windows slave) if the build is aborted/slave loses connection
Title: Message Title mark mann commented on JENKINS-38807 Re: Jenkins 2.7.4 seems to leave behind Java processes (on Windows slave) if the build is aborted/slave loses connection I have just noticed that WinSW is now on 2.0.1 I will upgrade and see if the problem still exists.. if it does, I will raise a separate bug thx! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-22024) Windows "services" shows Jenkins as not running.. but it is.
Title: Message Title mark mann commented on JENKINS-22024 Re: Windows "services" shows Jenkins as not running.. but it is. Jenkins master is on 2.32.1 Master and slaves running Win2012 The symptoms sound very familiar to a problem where we've had a jenkins slave up then we reboot the windows server (slave). When the server returns and the slave is automatically started, it hangs around for about 30secs then terminates connection which kills our job. We've also witnessed the hosting windows service winsw 1.17 (which auto upgrades to 1.18) bombs out but leaves the java process running. The java process is still keeping the slave active to the master for an indiscriminate amount of time (anywhere between 20secs to 2hrs) before eventually dying of its own accord, with no fresh jobs sent or interaction with the windows service. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39231) WinSW: Automatically terminate runaway processes in Windows services
Title: Message Title mark mann commented on JENKINS-39231 Re: WinSW: Automatically terminate runaway processes in Windows services Jenkins master is on 2.32.1 Master and slaves running Win2012 The symptoms sound very familiar to a problem where we've had a jenkins slave up then we reboot the windows server (slave). When the server returns and the slave is automatically started, it hangs around for about 30secs then terminates connection which kills our job. We've also witnessed the hosting windows service winsw 1.17 (which auto upgrades to 1.18) bombs out but leaves the java process running. The java process is still keeping the slave active to the master for an indiscriminate amount of time (anywhere between 20secs to 2hrs) before eventually dying of its own accord, with no fresh jobs sent or interaction with the windows service. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38807) Jenkins 2.7.4 seems to leave behind Java processes (on Windows slave) if the build is aborted/slave loses connection
Title: Message Title mark mann commented on JENKINS-38807 Re: Jenkins 2.7.4 seems to leave behind Java processes (on Windows slave) if the build is aborted/slave loses connection Jenkins master is on 2.32.1 Master and slaves running Win2012 The symptoms sound very familiar to a problem where we've had a jenkins slave up then we reboot the windows server (slave). When the server returns and the slave is automatically started, it hangs around for about 30secs then terminates connection which kills our job. We've also witnessed the hosting windows service winsw 1.17 (which auto upgrades to 1.18) bombs out but leaves the java process running. The java process is still keeping the slave active to the master for an indiscriminate amount of time (anywhere between 20secs to 2hrs) before eventually dying of its own accord, with no fresh jobs sent or interaction with the windows service. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] [core] (JENKINS-28492) The server rejected the connection: *** is already connected to this master. Rejecting this connection.
Title: Message Title mark mann commented on JENKINS-28492 Re: The server rejected the connection: *** is already connected to this master. Rejecting this connection. windows 2008R2 master and slaves master on Jenkins ver. 1.651.1 Java JRE is mixture of 8u60, 8u77, 8u91 I have >200 slaves and started seeing some of my "controller" slaves not wanting to start their jenkins slaves, especially when the slave has been reinstalled (as a refresh) the sample below is from a fresh slave, on 8u91. try to start the windows service hosting the slave and it stops immediately with the following log trace. May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: ComputerA May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener INFO: Jenkins agent is running in headless mode. May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://10.20.1.181:8080/jenkins/, http://jenkins:8080/jenkins/ May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to 10.20.1.181:55945 May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Trying protocol: JNLP2-connect May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Server didn't understand the protocol: ComputerA is already connected to this master. Rejecting this connection. May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to 10.20.1.181:55945 May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Trying protocol: JNLP-connect May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Server didn't understand the protocol: ComputerA is already connected to this master. Rejecting this connection. May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to 10.20.1.181:55945 May 17, 2016 5:45:58 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: None of the protocols were accepted java.lang.Exception: The server rejected the connection: None of the protocols were accepted at hudson.remoting.Engine.onConnectionRejected(Engine.java:297) at hudson.remoting.Engine.run(Engine.java:268) i've set the slave to "disconnected" on the master and then restart the service. sometimes it might then stay up, but not for long!! Add Comment This mes
[JIRA] [core] (JENKINS-25930) Race condition creating build links during concurrent builds causes build failures
Title: Message Title mark mann commented on JENKINS-25930 Re: Race condition creating build links during concurrent builds causes build failures i recently upgraded to Jenkins 1.651.1 (on windows) we make a lot of use of the parallel builds function... running 15 jobs in parallel. proportionately.. only a couple spit out this error... and can end up killing the entire job run. In the same parallel run, I can end up with different fault reasons among the jobs suggesting that dependent on the timing, a couple were competing with each other. eg: access denied, file already exists -- job@1 16:32:42 ln builds\lastStableBuild C:\.jenkins\jobs\X\lastStable failed 16:32:42 java.nio.file.AccessDeniedException: C:\.jenkins\jobs\X\lastStable 16:32:42 at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) 16:32:42 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:42 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:42 at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source) 16:32:42 at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(Unknown Source) 16:32:42 at java.nio.file.Files.deleteIfExists(Unknown Source) 16:32:42 at sun.reflect.GeneratedMethodAccessor1458.invoke(Unknown Source) 16:32:42 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 16:32:42 at java.lang.reflect.Method.invoke(Unknown Source) 16:32:42 at hudson.Util.createSymlinkJava7(Util.java:1233) 16:32:42 at hudson.Util.createSymlink(Util.java:1151) 16:32:42 at hudson.model.Run.createSymlink(Run.java:1840) 16:32:42 at hudson.model.Run.updateSymlinks(Run.java:1822) 16:32:42 at hudson.model.Run.execute(Run.java:1736) 16:32:42 at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:73) 16:32:42 at hudson.model.ResourceController.execute(ResourceController.java:98) 16:32:42 at hudson.model.Executor.run(Executor.java:410) -- job@2 16:32:41 ln builds\lastSuccessfulBuild C:\.jenkins\jobs\\lastSuccessful failed 16:32:41 java.nio.file.FileAlreadyExistsException: C:\.jenkins\jobs\X\lastSuccessful 16:32:41 at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsFileSystemProvider.createSymbolicLink(Unknown Source) 16:32:41 at java.nio.file.Files.createSymbolicLink(Unknown Source) 16:32:41 at sun.reflect.GeneratedMethodAccessor1459.invoke(Unknown Source) 16:32:41 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 16:32:41 at java.lang.reflect.Method.invoke(Unknown Source) 16:32:41 at hudson.Util.createSymlinkJava7(Util.java:1235) 16:32:41 at hudson.Util.createSymlink(Util.java:1151) 16:32:41 at hudson.model.Run.createSymlink(Run.java:1840) 16:32:41 at hudson.model.Run.updateSymlinks(Run.java:1821) 16:32:41 at hudson.model.Run.execute(Run.java:1736) 16:32:41 at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:73) 16:32:41 at hudson.model.ResourceController.execute(ResourceController.java:98) 16:32:41 at hudson.model.Executor.run(Executor.java:410)
[JIRA] [build-flow-plugin] (JENKINS-22516) FileAlreadyExistsException on parallel builds
Title: Message Title mark mann commented on JENKINS-22516 Re: FileAlreadyExistsException on parallel builds i recently upgraded to Jenkins 1.651.1 (on windows) we make a lot of use of the parallel builds function... running 15 jobs in parallel. the error message seems to be a common and annoying occurance... sometimes trashing a job. 16:32:41 ln builds\lastSuccessfulBuild C:\.jenkins\jobs\X\lastSuccessful failed 16:32:41 java.nio.file.FileAlreadyExistsException: C:\.jenkins\jobs\X\lastSuccessful 16:32:41 at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) 16:32:41 at sun.nio.fs.WindowsFileSystemProvider.createSymbolicLink(Unknown Source) 16:32:41 at java.nio.file.Files.createSymbolicLink(Unknown Source) 16:32:41 at sun.reflect.GeneratedMethodAccessor1459.invoke(Unknown Source) 16:32:41 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 16:32:41 at java.lang.reflect.Method.invoke(Unknown Source) 16:32:41 at hudson.Util.createSymlinkJava7(Util.java:1235) 16:32:41 at hudson.Util.createSymlink(Util.java:1151) 16:32:41 at hudson.model.Run.createSymlink(Run.java:1840) 16:32:41 at hudson.model.Run.updateSymlinks(Run.java:1821) 16:32:41 at hudson.model.Run.execute(Run.java:1736) 16:32:41 at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java:73) 16:32:41 at hudson.model.ResourceController.execute(ResourceController.java:98) 16:32:41 at hudson.model.Executor.run(Executor.java:410) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [core] (JENKINS-18781) Configurable channel timeout for slaves
mark mann
commented on JENKINS-18781
Configurable channel timeout for slaves
hey all...
some kind of Jenkins slave connection management settings would help.
I have desperately tried searching through all the config settings for slave and master, but cannot find a way of tuning the poll interval, length of timeout and number of retries to help diagnose or fix my issue.
Using vagrant, I'm spinning up a number of Windows VMs on vsphere and experiencing "random" socket resets or timeouts.
Below is a snippet of the error from the jenkins job trace. (Vagrant is at the point that it is polling the new VMs to discover when they are online and so the connection timeout from WinRM is as expected) however, during this polling cycle Jenkins falls over with the second part of the error trace... "java.net.SocketException: Connection reset"
surely there is a way of setting a number of retries or increasing the length of timeout?
if ($LASTEXITCODE) { exit $LASTEXITCODE } else { exit 0 }
Message: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. - connect(2) (http://10.30.40.12:5985)>
INFO winrm: Checking whether WinRM is ready...
INFO winrmshell: Attempting to connect to WinRM...
INFO winrmshell: - Host: 10.30.40.12
INFO winrmshell: - Port: 5985
INFO winrmshell: - Username: Administrator
FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:722)
at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167)
at com.sun.proxy.$Proxy45.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:950)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.plugins.msbuild.MsBuildBuilder.perform(MsBuildBuilder.java:180)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585)
at hudson.model.Run.execute(Run.java:1684)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:782)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:77)
at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at hudson.remoting.Command.readFrom(Command.java:92)
at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
