[JIRA] (JENKINS-17388) ssh-slaves 0.23: NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int)

Wed, 27 Mar 2013 08:35:15 -0700

Issue Type: Bug Bug
Assignee: Kohsuke Kawaguchi
Components: ssh-slaves
Created: 27/Mar/13 3:34 PM
Description:

After updating SSH Slaves plugin to 0.23 we get this when slave is starting: 

[03/27/13 10:07:14] [SSH] Checking java version of /home/hudson/JDK_HOME_1_6_0/bin/java
[03/27/13 10:07:15] [SSH] /home/hudson/JDK_HOME_1_6_0/bin/java -version returned 1.6.0_16.
[03/27/13 10:07:15] [SSH] Starting sftp client.
[03/27/13 10:07:15] [SSH] Copying latest slave.jar...
[03/27/13 10:07:15] [SSH] Copied 278,201 bytes.
ERROR: Failed to expand buffer size
java.lang.NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int)
	at java.lang.Class.getMethod(Class.java:1622)
	at hudson.plugins.sshslaves.SSHLauncher.expandChannelBufferSize(SSHLauncher.java:711)
	at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:661)
	at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:472)
	at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200)
	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:722)
[03/27/13 10:07:15] [SSH] Starting slave process: cd '/home/hudson/HUDSON_HOME' && /home/hudson/JDK_HOME_1_6_0/bin/java -Xmx1024m -XX:HeapDumpPath=/home/hudson/HUDSON_HOME/_dumps/ -jar slave.jar

<===[JENKINS REMOTING CAPACITY]===>channel started
Slave.jar version: 2.17
This is a Unix slave
Copied maven-agent.jar
Copied maven3-agent.jar
Copied maven3-interceptor.jar
Copied maven-interceptor.jar
Copied maven2.1-interceptor.jar
Copied plexus-classworld.jar
Copied classworlds.jar
Evacuated stdout
Slave successfully connected and online

We had to downgrade to SSH Slaves plugin to 0.22, which resolved the problem:

[03/27/13 10:16:32] [SSH] Checking java version of /home/hudson/JDK_HOME_1_6_0/bin/java
[03/27/13 10:16:33] [SSH] /home/hudson/JDK_HOME_1_6_0/bin/java -version returned 1.6.0_16.
[03/27/13 10:16:33] [SSH] Starting sftp client.
[03/27/13 10:16:33] [SSH] Copying latest slave.jar...
[03/27/13 10:16:33] [SSH] Copied 278,201 bytes.
[03/27/13 10:16:33] [SSH] Starting slave process: cd '/home/hudson/HUDSON_HOME' && /home/hudson/JDK_HOME_1_6_0/bin/java -Xmx1024m -XX:HeapDumpPath=/home/hudson/HUDSON_HOME/_dumps/ -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Slave.jar version: 2.17
This is a Unix slave
Copied maven-agent.jar
Copied maven3-agent.jar
Copied maven3-interceptor.jar
Copied maven-interceptor.jar
Copied maven2.1-interceptor.jar
Copied plexus-classworld.jar
Copied classworlds.jar
Evacuated stdout
Slave successfully connected and online

BTW, during this upgrade-...-downgrade process SSH slave credentials somehow got reset:

[03/27/13 10:14:02] [SSH] Opening SSH connection to jenkins-l64b.ourcompany.com:22.
[03/27/13 10:14:02] [SSH] Authenticating as jenkins/******.
[03/27/13 10:14:02] [SSH] Authentication failed.
hudson.AbortException: Authentication failed.
	at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:753)
	at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:278)
	at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200)
	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:722)
[03/27/13 10:14:02] [SSH] Connection closed.

We've been using hudson/jenkins for many years and had to switch to LTS since so called "normal" version would get broken in 95%+ of all plugin/Jenkins updates. And now we observe similar problem with LTS. I guess many Jenkins users would agree with me that this is not OK and something has to be done in this respect. The first thing that comes into my mind is introducing "Community ratings" for plugins too (helped us many times to avoid upgrading to unusable new version of "normal" Jenkins branch).
Environment: Server: Jenkins ver. 1.480.3 @ CentOS 6.3. Slaves: CentOS release 5.8, CentOS release 6.3.
Project: Jenkins
Priority: Major Major
Reporter: pancake
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

--
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/groups/opt_out.
 
 

Reply via email to