-
Bug
-
Resolution: Duplicate
-
Critical
-
None
When we upgraded from 1.545 to 1.549, we found that we could no longer launch our Windows slaves using the 'DCOM' method. Unfortunately we cannot use JNLP because these are libvirt slaves, and choosing JNLP causes the instances to not even start up (due to issues like JENKINS-8004).
What is happening is this:
- libvirt starts the slave
- Jenkins logs in to the slave
- It then tries to query the Java version
- ... and it all goes pear-shaped from here.
The stack trace is:
Error while launching <instance> on Hypervisor qemu+ssh://root@node2:22/system?no_verify=1&no_tty=1. java.lang.NoSuchMethodError: jcifs.smb.SmbFileInputStream.setTimeout(J)V at org.jvnet.hudson.remcom.WindowsRemoteProcessLauncher.openForRead(WindowsRemoteProcessLauncher.java:282) at org.jvnet.hudson.remcom.WindowsRemoteProcessLauncher.launch(WindowsRemoteProcessLauncher.java:140) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:233) at hudson.plugins.libvirt.VirtualMachineLauncher.launch(VirtualMachineLauncher.java:136) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:228) 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)
So it seems as though the jcifs used is maybe the wrong version (I see that it was patched some time in 2011 to include the 'setTimeout' function). Maybe it was reverted/removed? What could be the cause of this?
- duplicates
-
-
- Closed
-
