Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20276

Native Library Error after upgrading ssh-agent from 1.3 to 1.4

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      when starting an ssh agent on the slave the following stack trace occurs. Downgrading to 1.3 resolves the issue.

      Started by user Mark
      Building remotely on EC2-Jenkins-Slave (i-5a34613e) in workspace /var/jenkins/workspace/Mirror_Global_Commerce
      [ssh-agent] Using credentials jenkinsadmin
      [ssh-agent] Looking for ssh-agent implementation...
      [ssh-agent] Java/JNR ssh-agent
      [ssh-agent] FATAL: Could not find a suitable ssh-agent provider
      [ssh-agent] Diagnostic report
      [ssh-agent] * Java/JNR ssh-agent
      [ssh-agent] java.io.IOException: Remote call on EC2-Jenkins-Slave (i-5a34613e) failed
      [ssh-agent] at hudson.remoting.Channel.call(Channel.java:723)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentFactory.start(JNRRemoteAgentFactory.java:61)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:211)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:123)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:93)
      [ssh-agent] at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:78)
      [ssh-agent] at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:556)
      [ssh-agent] at hudson.model.Run.execute(Run.java:1665)
      [ssh-agent] at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      [ssh-agent] at hudson.model.ResourceController.execute(ResourceController.java:88)
      [ssh-agent] at hudson.model.Executor.run(Executor.java:230)
      [ssh-agent] Caused by: java.lang.UnsatisfiedLinkError: /lib/libc.so.6: wrong ELF class: ELFCLASS32
      [ssh-agent] at jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:87)
      [ssh-agent] at jnr.ffi.provider.jffi.NativeLibrary.getNativeLibraries(NativeLibrary.java:70)
      [ssh-agent] at jnr.ffi.provider.jffi.NativeLibrary.getSymbolAddress(NativeLibrary.java:49)
      [ssh-agent] at jnr.ffi.provider.jffi.NativeLibrary.findSymbolAddress(NativeLibrary.java:59)
      [ssh-agent] at jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:125)
      [ssh-agent] at jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:63)
      [ssh-agent] at jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:43)
      [ssh-agent] at jnr.ffi.LibraryLoader.load(LibraryLoader.java:228)
      [ssh-agent] at jnr.ffi.Library.loadLibrary(Library.java:123)
      [ssh-agent] at jnr.ffi.Library.loadLibrary(Library.java:80)
      [ssh-agent] at jnr.unixsocket.Native$LibC.<clinit>(Native.java:40)
      [ssh-agent] at jnr.unixsocket.Native.libsocket(Native.java:60)
      [ssh-agent] at jnr.unixsocket.Native.socket(Native.java:68)
      [ssh-agent] at jnr.unixsocket.UnixServerSocketChannel.<init>(UnixServerSocketChannel.java:38)
      [ssh-agent] at jnr.unixsocket.UnixServerSocket.<init>(UnixServerSocket.java:29)
      [ssh-agent] at jnr.unixsocket.UnixServerSocketChannel.open(UnixServerSocketChannel.java:48)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.AgentServer.start(AgentServer.java:67)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.<init>(JNRRemoteAgent.java:64)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:54)
      [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:35)
      [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      [ssh-agent] at hudson.remoting.Request$2.run(Request.java:326)
      [ssh-agent] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      [ssh-agent] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      [ssh-agent] at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      [ssh-agent] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
      [ssh-agent] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      [ssh-agent] at java.lang.Thread.run(Thread.java:679)
      FATAL: [ssh-agent] Unable to start agent
      hudson.util.IOException2: [ssh-agent] Unable to start agent
      at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:130)
      at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:93)
      at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:78)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:556)
      at hudson.model.Run.execute(Run.java:1665)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:230)
      Caused by: java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider.
      at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:229)
      at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:123)
      ... 7 more

        Attachments

          Activity

          Hide
          stephenconnolly Stephen Connolly added a comment -

          Ok, I think I have the root cause.

          The issue here is that Java, by default, can end up having the 32-bit library paths in the java.library.path system property and there is a bug in JNR's Platform.Linux:

                  @Override
                  public String locateLibrary(final String libName, List<String> libraryPath) {
                      FilenameFilter filter = new FilenameFilter() {
                          Pattern p = Pattern.compile("lib" + libName + "\\.so\\.[0-9]+$");
                          String exact = "lib" + libName + ".so";
                          public boolean accept(File dir, String name) {
                              return p.matcher(name).matches() || exact.equals(name);
                          }
                      };
          
                      List<File> matches = new LinkedList<File>();
                      for (String path : libraryPath) {
                          File[] files = new File(path).listFiles(filter);
                          if (files != null && files.length > 0) {
                              matches.addAll(Arrays.asList(files));
                          }
                      }
          
                      //
                      // Search through the results and return the highest numbered version
                      // i.e. libc.so.6 is preferred over libc.so.5
                      //
                      int version = 0;
                      String bestMatch = null;
                      for (File file : matches) {
                          String path = file.getAbsolutePath();
                          if (bestMatch == null && path.endsWith(".so")) {
                              bestMatch = path;
                              version = 0;
                          } else {
                              String num = path.substring(path.lastIndexOf(".so.") + 4);
                              try {
                                  if (Integer.parseInt(num) >= version) {
                                      bestMatch = path;
                                  }
                              } catch (NumberFormatException e) {
                              } // Just skip if not a number
                          }
                      }
                      return bestMatch != null ? bestMatch : mapLibraryName(libName);
                  }
          

          The bug being that it will return the last match is all the matches have the same version (I suspect it is that (Integer.parseInt(num) >= version) should be (Integer.parseInt(num) > version) but I am not currently sure, as I have yet to dig into this fully)

          So what you need to ensure is that the library paths (if they include a mix of 64bit and 32bit libraries) are a palindrome, now the search path is a combination of four system properties in order:

          • jnr.ffi.library.path
          • jaffl.library.path
          • jna.library.path
          • java.library.path

          So what you want to do is see what the combined path for all of those is... and then (since you are here because there is a 32bit lib on that path) reverse the path and append it to java.library.path

          A quicker fix is to just remove the 32-bit folders from java.library.path

          By way of example, if I go to the System Information page for my CentOS 6.5 slave, I see that it says:

          java.library.path /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
          

          So I can either set the JVM options for that slave to include -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib:/lib:/lib64:/usr/lib64:/usr/java/packages/lib/amd64 (which is the palindrome trick) or I can simply remove the 32-bit directories from -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64

          Either of these fixes the issue

          Show
          stephenconnolly Stephen Connolly added a comment - Ok, I think I have the root cause. The issue here is that Java, by default, can end up having the 32-bit library paths in the java.library.path system property and there is a bug in JNR's Platform.Linux : @Override public String locateLibrary( final String libName, List< String > libraryPath) { FilenameFilter filter = new FilenameFilter() { Pattern p = Pattern.compile( "lib" + libName + "\\.so\\.[0-9]+$" ); String exact = "lib" + libName + ".so" ; public boolean accept(File dir, String name) { return p.matcher(name).matches() || exact.equals(name); } }; List<File> matches = new LinkedList<File>(); for ( String path : libraryPath) { File[] files = new File(path).listFiles(filter); if (files != null && files.length > 0) { matches.addAll(Arrays.asList(files)); } } // // Search through the results and return the highest numbered version // i.e. libc.so.6 is preferred over libc.so.5 // int version = 0; String bestMatch = null ; for (File file : matches) { String path = file.getAbsolutePath(); if (bestMatch == null && path.endsWith( ".so" )) { bestMatch = path; version = 0; } else { String num = path.substring(path.lastIndexOf( ".so." ) + 4); try { if ( Integer .parseInt(num) >= version) { bestMatch = path; } } catch (NumberFormatException e) { } // Just skip if not a number } } return bestMatch != null ? bestMatch : mapLibraryName(libName); } The bug being that it will return the last match is all the matches have the same version (I suspect it is that (Integer.parseInt(num) >= version) should be (Integer.parseInt(num) > version) but I am not currently sure, as I have yet to dig into this fully) So what you need to ensure is that the library paths (if they include a mix of 64bit and 32bit libraries) are a palindrome, now the search path is a combination of four system properties in order: jnr.ffi.library.path jaffl.library.path jna.library.path java.library.path So what you want to do is see what the combined path for all of those is... and then (since you are here because there is a 32bit lib on that path) reverse the path and append it to java.library.path A quicker fix is to just remove the 32-bit folders from java.library.path By way of example, if I go to the System Information page for my CentOS 6.5 slave, I see that it says: java.library.path /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib So I can either set the JVM options for that slave to include -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib:/lib:/lib64:/usr/lib64:/usr/java/packages/lib/amd64 (which is the palindrome trick) or I can simply remove the 32-bit directories from -Djava.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64 Either of these fixes the issue
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Stephen Connolly
          Path:
          pom.xml
          http://jenkins-ci.org/commit/ssh-agent-plugin/f01905a36986880b94fb0e8ca368e37b11547149
          Log:
          [FIXED JENKINS-20276] Use a patched version of jnr-ffi

          While we await the merge of https://github.com/jnr/jnr-ffi/pull/23

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: pom.xml http://jenkins-ci.org/commit/ssh-agent-plugin/f01905a36986880b94fb0e8ca368e37b11547149 Log: [FIXED JENKINS-20276] Use a patched version of jnr-ffi While we await the merge of https://github.com/jnr/jnr-ffi/pull/23
          Hide
          stephenconnolly Stephen Connolly added a comment -

          1.4.2 has the fix

          Show
          stephenconnolly Stephen Connolly added a comment - 1.4.2 has the fix
          Hide
          godlin23 arkady godlin added a comment -

          still getting this error on 1 of the machines i have
          my configuration
          OS: CentOS-4.8
          SSH Agent Plugin: 1.5
          SSH Credentials Plugin : 1.8
          Credentials Plugin : 1.16
          java version "1.6.0_45"

          [EnvInject] - Loading node environment variables.
          Building remotely on sdel64-12 (CentOS-4.8 sde CentOS lin internal-rs amd64-CentOS-4.8 linux 4.8 amd64-CentOS amd64) in workspace /home/emxtest2/emx/internal-rs/workspace/SDE-tmp
          [ssh-agent] Using credentials emxtest (emxtest)
          [ssh-agent] Looking for ssh-agent implementation...
          [ssh-agent] Java/JNR ssh-agent
          [ssh-agent] FATAL: Could not find a suitable ssh-agent provider
          [ssh-agent] Diagnostic report
          [ssh-agent] * Java/JNR ssh-agent
          [ssh-agent] java.io.IOException: Remote call on sdel64-12 failed
          [ssh-agent] at hudson.remoting.Channel.call(Channel.java:748)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentFactory.start(JNRRemoteAgentFactory.java:61)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:314)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:224)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:189)
          [ssh-agent] at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:76)
          [ssh-agent] at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
          [ssh-agent] at hudson.model.Run.execute(Run.java:1740)
          [ssh-agent] at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          [ssh-agent] at hudson.model.ResourceController.execute(ResourceController.java:88)
          [ssh-agent] at hudson.model.Executor.run(Executor.java:234)
          [ssh-agent] Caused by: java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider
          [ssh-agent] at jnr.ffi.provider.InvalidRuntime.newLoadError(InvalidRuntime.java:83)
          [ssh-agent] at jnr.ffi.provider.InvalidRuntime.findType(InvalidRuntime.java:24)
          [ssh-agent] at jnr.ffi.Struct$NumberField.<init>(Struct.java:649)
          [ssh-agent] at jnr.ffi.Struct$Unsigned16.<init>(Struct.java:1007)
          [ssh-agent] at jnr.unixsocket.SockAddrUnix$DefaultSockAddrUnix.<init>(SockAddrUnix.java:129)
          [ssh-agent] at jnr.unixsocket.SockAddrUnix.create(SockAddrUnix.java:99)
          [ssh-agent] at jnr.unixsocket.UnixSocketAddress.<init>(UnixSocketAddress.java:32)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.AgentServer.start(AgentServer.java:66)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.<init>(JNRRemoteAgent.java:64)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:54)
          [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:35)
          [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          [ssh-agent] at hudson.remoting.Request$2.run(Request.java:328)
          [ssh-agent] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
          [ssh-agent] at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          [ssh-agent] at java.util.concurrent.FutureTask.run(Unknown Source)
          [ssh-agent] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
          [ssh-agent] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          [ssh-agent] at java.lang.Thread.run(Unknown Source)
          [ssh-agent] Caused by: java.lang.ExceptionInInitializerError
          [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.getInstance(NativeRuntime.java:49)
          [ssh-agent] at jnr.ffi.provider.jffi.Provider.<init>(Provider.java:29)
          [ssh-agent] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          [ssh-agent] at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
          [ssh-agent] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
          [ssh-agent] at java.lang.reflect.Constructor.newInstance(Unknown Source)
          [ssh-agent] at java.lang.Class.newInstance0(Unknown Source)
          [ssh-agent] at java.lang.Class.newInstance(Unknown Source)
          [ssh-agent] at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.getInstance(FFIProvider.java:60)
          [ssh-agent] at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.<clinit>(FFIProvider.java:49)
          [ssh-agent] at jnr.ffi.provider.FFIProvider.getSystemProvider(FFIProvider.java:35)
          [ssh-agent] at jnr.ffi.Runtime$SingletonHolder.<clinit>(Runtime.java:85)
          [ssh-agent] at jnr.ffi.Runtime.getSystemRuntime(Runtime.java:70)
          [ssh-agent] at jnr.unixsocket.SockAddrUnix.<init>(SockAddrUnix.java:34)
          [ssh-agent] at jnr.unixsocket.SockAddrUnix$DefaultSockAddrUnix.<init>(SockAddrUnix.java:128)
          [ssh-agent] ... 15 more
          [ssh-agent] Caused by: java.lang.IllegalStateException: Can't overwrite cause
          [ssh-agent] at java.lang.Throwable.initCause(Throwable.java:320)
          [ssh-agent] at com.kenai.jffi.Type$Builtin.lookupTypeInfo(Type.java:252)
          [ssh-agent] at com.kenai.jffi.Type$Builtin.getTypeInfo(Type.java:237)
          [ssh-agent] at com.kenai.jffi.Type.resolveSize(Type.java:155)
          [ssh-agent] at com.kenai.jffi.Type.size(Type.java:138)
          [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime$TypeDelegate.size(NativeRuntime.java:178)
          [ssh-agent] at jnr.ffi.provider.AbstractRuntime.<init>(AbstractRuntime.java:48)
          [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:57)
          [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:41)
          [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime$SingletonHolder.<clinit>(NativeRuntime.java:53)
          [ssh-agent] ... 30 more
          FATAL: [ssh-agent] Unable to start agent
          hudson.util.IOException2: [ssh-agent] Unable to start agent
          at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:231)
          at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:189)
          at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:76)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
          at hudson.model.Run.execute(Run.java:1740)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:234)
          Caused by: java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider.
          at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:332)
          at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:224)
          ... 7 more

          is this could be because of the old OS ?

          Show
          godlin23 arkady godlin added a comment - still getting this error on 1 of the machines i have my configuration OS: CentOS-4.8 SSH Agent Plugin: 1.5 SSH Credentials Plugin : 1.8 Credentials Plugin : 1.16 java version "1.6.0_45" [EnvInject] - Loading node environment variables. Building remotely on sdel64-12 (CentOS-4.8 sde CentOS lin internal-rs amd64-CentOS-4.8 linux 4.8 amd64-CentOS amd64) in workspace /home/emxtest2/emx/internal-rs/workspace/SDE-tmp [ssh-agent] Using credentials emxtest (emxtest) [ssh-agent] Looking for ssh-agent implementation... [ssh-agent] Java/JNR ssh-agent [ssh-agent] FATAL: Could not find a suitable ssh-agent provider [ssh-agent] Diagnostic report [ssh-agent] * Java/JNR ssh-agent [ssh-agent] java.io.IOException: Remote call on sdel64-12 failed [ssh-agent] at hudson.remoting.Channel.call(Channel.java:748) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentFactory.start(JNRRemoteAgentFactory.java:61) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:314) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:224) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:189) [ssh-agent] at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:76) [ssh-agent] at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) [ssh-agent] at hudson.model.Run.execute(Run.java:1740) [ssh-agent] at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) [ssh-agent] at hudson.model.ResourceController.execute(ResourceController.java:88) [ssh-agent] at hudson.model.Executor.run(Executor.java:234) [ssh-agent] Caused by: java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider [ssh-agent] at jnr.ffi.provider.InvalidRuntime.newLoadError(InvalidRuntime.java:83) [ssh-agent] at jnr.ffi.provider.InvalidRuntime.findType(InvalidRuntime.java:24) [ssh-agent] at jnr.ffi.Struct$NumberField.<init>(Struct.java:649) [ssh-agent] at jnr.ffi.Struct$Unsigned16.<init>(Struct.java:1007) [ssh-agent] at jnr.unixsocket.SockAddrUnix$DefaultSockAddrUnix.<init>(SockAddrUnix.java:129) [ssh-agent] at jnr.unixsocket.SockAddrUnix.create(SockAddrUnix.java:99) [ssh-agent] at jnr.unixsocket.UnixSocketAddress.<init>(UnixSocketAddress.java:32) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.AgentServer.start(AgentServer.java:66) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgent.<init>(JNRRemoteAgent.java:64) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:54) [ssh-agent] at com.cloudbees.jenkins.plugins.sshagent.jna.JNRRemoteAgentStarter.call(JNRRemoteAgentStarter.java:35) [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:118) [ssh-agent] at hudson.remoting.UserRequest.perform(UserRequest.java:48) [ssh-agent] at hudson.remoting.Request$2.run(Request.java:328) [ssh-agent] at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) [ssh-agent] at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) [ssh-agent] at java.util.concurrent.FutureTask.run(Unknown Source) [ssh-agent] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [ssh-agent] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [ssh-agent] at java.lang.Thread.run(Unknown Source) [ssh-agent] Caused by: java.lang.ExceptionInInitializerError [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.getInstance(NativeRuntime.java:49) [ssh-agent] at jnr.ffi.provider.jffi.Provider.<init>(Provider.java:29) [ssh-agent] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [ssh-agent] at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) [ssh-agent] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) [ssh-agent] at java.lang.reflect.Constructor.newInstance(Unknown Source) [ssh-agent] at java.lang.Class.newInstance0(Unknown Source) [ssh-agent] at java.lang.Class.newInstance(Unknown Source) [ssh-agent] at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.getInstance(FFIProvider.java:60) [ssh-agent] at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.<clinit>(FFIProvider.java:49) [ssh-agent] at jnr.ffi.provider.FFIProvider.getSystemProvider(FFIProvider.java:35) [ssh-agent] at jnr.ffi.Runtime$SingletonHolder.<clinit>(Runtime.java:85) [ssh-agent] at jnr.ffi.Runtime.getSystemRuntime(Runtime.java:70) [ssh-agent] at jnr.unixsocket.SockAddrUnix.<init>(SockAddrUnix.java:34) [ssh-agent] at jnr.unixsocket.SockAddrUnix$DefaultSockAddrUnix.<init>(SockAddrUnix.java:128) [ssh-agent] ... 15 more [ssh-agent] Caused by: java.lang.IllegalStateException: Can't overwrite cause [ssh-agent] at java.lang.Throwable.initCause(Throwable.java:320) [ssh-agent] at com.kenai.jffi.Type$Builtin.lookupTypeInfo(Type.java:252) [ssh-agent] at com.kenai.jffi.Type$Builtin.getTypeInfo(Type.java:237) [ssh-agent] at com.kenai.jffi.Type.resolveSize(Type.java:155) [ssh-agent] at com.kenai.jffi.Type.size(Type.java:138) [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime$TypeDelegate.size(NativeRuntime.java:178) [ssh-agent] at jnr.ffi.provider.AbstractRuntime.<init>(AbstractRuntime.java:48) [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:57) [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:41) [ssh-agent] at jnr.ffi.provider.jffi.NativeRuntime$SingletonHolder.<clinit>(NativeRuntime.java:53) [ssh-agent] ... 30 more FATAL: [ssh-agent] Unable to start agent hudson.util.IOException2: [ssh-agent] Unable to start agent at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:231) at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.preCheckout(SSHAgentBuildWrapper.java:189) at jenkins.scm.SCMCheckoutStrategy.preCheckout(SCMCheckoutStrategy.java:76) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.lang.RuntimeException: [ssh-agent] Could not find a suitable ssh-agent provider. at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper$SSHAgentEnvironment.<init>(SSHAgentBuildWrapper.java:332) at com.cloudbees.jenkins.plugins.sshagent.SSHAgentBuildWrapper.createSSHAgentEnvironment(SSHAgentBuildWrapper.java:224) ... 7 more is this could be because of the old OS ?
          Hide
          stephenconnolly Stephen Connolly added a comment - - edited

          It could be. CentOS 4.8 is rather old alright (2009 being 5 years ago).

          I would rather have you install the tomcat native components on that slave it should "just work" as you can compile them for that slave's architecture and bypass all the fun of jffi

          Show
          stephenconnolly Stephen Connolly added a comment - - edited It could be. CentOS 4.8 is rather old alright (2009 being 5 years ago). I would rather have you install the tomcat native components on that slave it should "just work" as you can compile them for that slave's architecture and bypass all the fun of jffi

            People

            • Assignee:
              Unassigned
              Reporter:
              mklunder Mark Klunder
            • Votes:
              6 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: