failure setting up slave...
Locked
failure setting up slave...
 
|
I'm trying to set up my first slave and I'm running into a problem I
don't understand or know how to debug.
Both machines are ubuntu-12.04, standard ubuntu jenkins install, configured for " Project-based Matrix Authorization Strategy". It looks to me as though my script has successfully contacted the slave, downloaded slave.jar, and launched it, but for reasons that aren't clear, the jenkins protocol is getting screwed up. Can anyone tell me what this might mean? --rich [07/27/12 14:12:36] Launching slave agent $ /bin/sh -x /var/lib/jenkins/runslave.sh ape.palm.com + set -e + '[' -n ape.palm.com ']' + target=/home/jenkins/slave.jar + ssh ape.palm.com wget -q --auth-no-challenge --no-check-certificate -O /home/jenkins/slave.jar-new https://slave:pointless@.../jenkins/jnlpJars/slave.jar + ssh ape.palm.com mv /home/jenkins/slave.jar-new /home/jenkins/slave.jar + ssh ape.palm.com /usr/bin/java -jar /home/jenkins/slave.jar <===[JENKINS REMOTING CAPACITY]===>channel started Ping failed. Terminating ERROR: Connection terminated ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1037) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570) at hudson.remoting.Request.call(Request.java:149) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314) at hudson.remoting.Channel.call(Channel.java:668) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:333) at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:121) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1031) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:198) ERROR: Process terminated with exit code 255 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:719) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1060) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1037) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2570) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1031) |
Re: failure setting up slave...
|
From which package does "java" on the slave come from? -- Sami
|
Re: failure setting up slave...
|
Can you normally SSH to the slave machine from Master? I got some weird errors that disappeared after Firewall is relaxed ...
Krishna Chaitanya On Sun, Jul 29, 2012 at 11:55 AM, Sami Tikka <[hidden email]> wrote:
|
Re: failure setting up slave...
|
|
In reply to this post by Sami Tikka
Standard ubuntu-12.04 openjdk:
rich@gecko> java --version Unrecognized option: --version Could not create the Java virtual machine. rich@gecko> java -version java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-1ubuntu0.12.04.1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) rich@gecko> dpkg -l | grep openjdk ii openjdk-6-jre 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime, using Hotspot JIT ii openjdk-6-jre-headless 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime, using Hotspot JIT (headless) ii openjdk-6-jre-lib 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime (architecture independent libraries) rich@ape> java -version java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-1ubuntu0.12.04.1) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) rich@ape> dpkg -l | grep openjdk ii openjdk-6-jre 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime, using Hotspot JIT ii openjdk-6-jre-headless 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime, using Hotspot JIT (headless) ii openjdk-6-jre-lib 6b24-1.11.3-1ubuntu0.12.04.1 OpenJDK Java runtime (architecture independent libraries) --rich On 7/29/12 11:55 , Sami Tikka wrote:
|
Re: failure setting up slave...
|
|
In reply to this post by krishna chaitanya kurnala
I just triple checked and yes, it's all set up and ssh works fine,
password free (public key), in both directions.
--rich On 7/29/12 12:07 , krishna chaitanya
kurnala wrote:
Can you normally SSH to the slave machine from Master? I got some weird errors that disappeared after Firewall is relaxed ... |
Re: failure setting up slave...
|
|
In reply to this post by Sami Tikka
I've gotten this working. The clue for me was here:
http://jenkins.361315.n4.nabble.com/Doing-something-else-before-invoking-slave-jar-in-slave-launch-script-td4634608.html There appears to be a bug in the jenkins protocol but adding -n to the earlier ssh commands in my runslave.sh script appears to work around the bug. --rich |
Re: failure setting up slave...
|
|
Doh! Of course!
I don't really think it is Jenkins' fault the earlier ssh clients ate the first protocol messages. -- Sami Rich Pixley <[hidden email]> kirjoitti 30.7.2012 kello 21.40: > I've gotten this working. The clue for me was here: http://jenkins.361315.n4.nabble.com/Doing-something-else-before-invoking-slave-jar-in-slave-launch-script-td4634608.html > > There appears to be a bug in the jenkins protocol but adding -n to the earlier ssh commands in my runslave.sh script appears to work around the bug. > > --rich |
Re: failure setting up slave...
|
|
I do.
The protocol should have a more robust initial negotiation in order to cover exactly this extremely common case. Even reversing the initial protocol message so that it comes from the slave would probably do the job. --rich On 7/30/12 11:50 , Sami Tikka wrote: > Doh! Of course! > > I don't really think it is Jenkins' fault the earlier ssh clients ate the first protocol messages. > > -- Sami > > Rich Pixley <[hidden email]> kirjoitti 30.7.2012 kello 21.40: > >> I've gotten this working. The clue for me was here: http://jenkins.361315.n4.nabble.com/Doing-something-else-before-invoking-slave-jar-in-slave-launch-script-td4634608.html >> >> There appears to be a bug in the jenkins protocol but adding -n to the earlier ssh commands in my runslave.sh script appears to work around the bug. >> >> --rich |
Re: failure setting up slave...
|
|
If you feel strongly about it, you can open a bug report and even contribute the improvement to the protocol. I'm sure the Jenkins committers will welcome the contribution.
And if java coding isn't your cup of tea, you can also help others by adding a page to Jenkins wiki about this. -- Sami Rich Pixley <[hidden email]> kirjoitti 31.7.2012 kello 0.12: > I do. > > The protocol should have a more robust initial negotiation in order to cover exactly this extremely common case. Even reversing the initial protocol message so that it comes from the slave would probably do the job. > > --rich > > On 7/30/12 11:50 , Sami Tikka wrote: >> Doh! Of course! >> >> I don't really think it is Jenkins' fault the earlier ssh clients ate the first protocol messages. >> >> -- Sami >> >> Rich Pixley <[hidden email]> kirjoitti 30.7.2012 kello 21.40: >> >>> I've gotten this working. The clue for me was here: http://jenkins.361315.n4.nabble.com/Doing-something-else-before-invoking-slave-jar-in-slave-launch-script-td4634608.html >>> >>> There appears to be a bug in the jenkins protocol but adding -n to the earlier ssh commands in my runslave.sh script appears to work around the bug. >>> >>> --rich |
«
Return to Jenkins users
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |