[JIRA] [libvirt-slave] (JENKINS-23233) Libvirt does not shut down slaves after last upgrade of plugin
Johan Cronje commented on JENKINS-23233 Libvirt does not shut down slaves after last upgrade of plugin From the logs, it seems the problem is when trying to shut down the machine: Jun 13, 2014 10:43:46 AM SEVERE hudson.remoting.Channel$2 handle Failed to execute command close (channel devel-win64-node1) java.lang.NullPointerException at java.util.regex.Matcher.getTextLength(Matcher.java:1234) at java.util.regex.Matcher.reset(Matcher.java:308) at java.util.regex.Matcher.init(Matcher.java:228) at java.util.regex.Pattern.matcher(Pattern.java:1088) at java.util.Formatter.parse(Formatter.java:2515) at java.util.Formatter.format(Formatter.java:2469) at java.util.Formatter.format(Formatter.java:2423) at java.lang.String.format(String.java:2797) at hudson.util.StreamTaskListener.fatalError(StreamTaskListener.java:153) at hudson.plugins.libvirt.VirtualMachineLauncher.afterDisconnect(VirtualMachineLauncher.java:192) at hudson.slaves.SlaveComputer$2.onClosed(SlaveComputer.java:443) at hudson.remoting.Channel.terminate(Channel.java:819) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:951) at hudson.remoting.Channel$2.handle(Channel.java:475) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Jun 13, 2014 10:43:46 AM SEVERE hudson.remoting.Channel$2 handle This command is created here Command close created at at hudson.remoting.Command.init(Command.java:56) at hudson.remoting.Channel$CloseCommand.init(Channel.java:945) at hudson.remoting.Channel$CloseCommand.init(Channel.java:943) at hudson.remoting.Channel.close(Channel.java:1026) at hudson.remoting.Channel.close(Channel.java:1009) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:950) at hudson.remoting.Channel$2.handle(Channel.java:475) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) 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/d/optout.
[JIRA] [windows-slaves] (JENKINS-21542) Cannot launch Windows libvirt slaves due to missing method on SmbFileInputStream
Johan Cronje commented on JENKINS-21542 Cannot launch Windows libvirt slaves due to missing method on SmbFileInputStream Verified that downgrading to 1.545 solved the issue for us. 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.
[JIRA] [windows-slaves] (JENKINS-21542) Cannot launch Windows libvirt slaves due to missing method on SmbFileInputStream
Johan Cronje created JENKINS-21542 Cannot launch Windows libvirt slaves due to missing method on SmbFileInputStream Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: windows-slaves Created: 29/Jan/14 8:38 AM Description: 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=1no_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? Project: Jenkins Priority: Critical Reporter: Johan Cronje 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.
[JIRA] [active-directory] (JENKINS-17803) AD plugin 1.3.1 doesn't handle non-ascii names correctly
Johan Cronje created JENKINS-17803 AD plugin 1.3.1 doesnt handle non-ascii names correctly Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: active-directory Created: 30/Apr/13 1:56 PM Description: We just upgraded AD plugin to 1.3.1. Now I am unable to log in, it seems to be due to my surname containing an 'é'. Verified by downgrading to 1.3.0, then all is well. Here is the log: org.acegisecurity.BadCredentialsException: Failed to retrieve user information for jcronje; nested exception is javax.naming.InvalidNameException: CN=Johan Cronj\u00E9,OU=Internal,OU=Users,OU=EMSS,DC=domain,DC=,DC=: [LDAP: error code 34 - 208F: LdapErr: DSID-0C090715, comment: Error processing name, data 0, v1db1]; remaining name 'CN=Johan Cronj\u00E9,OU=Internal,OU=Users,OU=EMSS,DC=,DC=,DC=' at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:309) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:193) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:137) at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:122) at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:200) at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:47) at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:74) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:64) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:227) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) 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:636) Caused by: javax.naming.InvalidNameException: CN=Johan
