Status: Resolved (View Workflow)
I upgraded from 1.573 to 1.597 (and apparently the downgrade path is painful) and suddenly all my linux ec2 slaves can't connect
Getting this stack trace in the slave connect logs
Node jenkins-aws-centos-6.5-64-LinuxBuildOrTest-v1.4 (i-70f6ea9c)(i-70f6ea9c) is ready Connecting to ec2-54-159-86-48.compute-1.amazonaws.com on port 22, with timeout 10000. Connected via SSH. bootstrap() Getting keypair... Using key: -------- Authenticating as ------- take over connection Creating tmp directory () if it does not exist mkdir: missing operand Try `mkdir --help' for more information. Verifying that java exists java full version "1.7.0_51-b13" Copying slave.jar Launching slave agent: java -jar /slave.jar ERROR: unexpected stream termination java.io.EOFException: unexpected stream termination at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:331) at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:280) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:365) at hudson.plugins.ec2.ssh.EC2UnixLauncher.launch(EC2UnixLauncher.java:172) at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:107) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:241) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)
JENKINS-26531 Slave does not start if the temp dir is not set to anything after upgrade to 1.25
Steve Donie added a comment - - edited
Appears to be a duplicate of
I changed the ec2 configuration so that the temporary dir was set to /tmp (which should be the default) and then provisioned a new EC2 instance. It connected as expected.
Steve Donie added a comment - - edited Appears to be a duplicate of JENKINS-26531 I changed the ec2 configuration so that the temporary dir was set to /tmp (which should be the default) and then provisioned a new EC2 instance. It connected as expected.
I manually SSH'd to the slave machine, changed to the root directory, and then listed the files there. There was no slave.jar listed. I then ran this command in the root dir:
which downloaded the jar as expected. Finally I went back to the build server web UI, selected the node in Build Executor status, and selected 'Launch slave agent' - success!
So it appears that the location the slave.jar is copied and the location that is used to launch it are not the same, and it appears to be launching it expecting it to be in the root.