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

Remoting -fullversion should fail if it finds Java 8

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ec2-plugin
    • None
    • Jenkins Version: 2.361.1 (LTS)
      org.jenkins-ci.main:remoting:3044.vb_940a_a_e4f72e
      Amazon EC2 plugin: 2.0.2

      When starting an agent Jenkins checks the -fullversion of the java binary and reports this to the console. In 2.361.1 LTS support for Java 8 was removed and the remoting JAR only works with Java 11.

      When checking the java version it could fail fast and produce an appropriate error that leads the user to discover that Java 8 is no longer supported for remoting.

      Currently the remoting jar just fails with the following error message instead:

      Sep 12, 2022 11:02:39 AM hudson.plugins.ec2.EC2Cloud
      INFO: Creating ~/.hudson-run-init
      Sep 12, 2022 11:02:39 AM hudson.plugins.ec2.EC2Cloud
      INFO: Verifying: java -fullversion
      openjdk full version "1.8.0_332-b09"
      Sep 12, 2022 11:02:39 AM hudson.plugins.ec2.EC2Cloud
      INFO: Verifying: which scp
      /usr/bin/scp
      Sep 12, 2022 11:02:39 AM hudson.plugins.ec2.EC2Cloud
      INFO: Copying remoting.jar to: /tmp
      Sep 12, 2022 11:02:40 AM hudson.plugins.ec2.EC2Cloud
      INFO: Launching remoting agent (via SSH client process): ssh -o StrictHostKeyChecking=no -i /tmp/ec2_6766237153533058907.pem jenkins@10.10.102.105 -p 22  java  -jar /tmp/remoting.jar -workDir /home/jenkins
      [09/12/22 11:02:40] Launching agent
      $ ssh -o StrictHostKeyChecking=no -i /tmp/ec2_6766237153533058907.pem jenkins@10.10.102.105 -p 22  java  -jar /tmp/remoting.jar -workDir /home/jenkins
      Warning: Permanently added '10.10.102.105' (ECDSA) to the list of known hosts.
      Error: A JNI error has occurred, please check your installation and try again
      Exception in thread "main" java.lang.UnsupportedClassVersionError: hudson/remoting/Launcher has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
      	at java.lang.ClassLoader.defineClass1(Native Method)
      	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
      	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
      	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
      	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
      	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
      	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
      	at java.security.AccessController.doPrivileged(Native Method)
      	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
      	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
      	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
      ERROR: Unable to launch the agent for EC2 (ap-southeast-2) - admin (i-0b7aab3f7d7cc5efd)
      java.io.EOFException: unexpected stream termination
      	at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:459)
      	at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:404)
      	at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:437)
      	at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:170)
      	at hudson.plugins.ec2.ssh.EC2UnixLauncher.launchScript(EC2UnixLauncher.java:270)
      	at hudson.plugins.ec2.EC2ComputerLauncher.launch(EC2ComputerLauncher.java:48)
      	at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:298)
      	at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:48)
      	at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:82)
      	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
      	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
      	at java.base/java.lang.Thread.run(Thread.java:829)
      

          [JENKINS-69581] Remoting -fullversion should fail if it finds Java 8

          Basil Crow added a comment -

          We would welcome a pull request implementing an improvement along these lines. In the meantime, this is already documented in the 2.361.1 LTS upgrade guide.

          Basil Crow added a comment - We would welcome a pull request implementing an improvement along these lines. In the meantime, this is already documented in the 2.361.1 LTS upgrade guide.

          I had a play around with this to see what I could do but in the end I didn't really have enough time to implement what I was after, and I also don't have much Java expereince which probably didn't help. I totally agree with you that since it's mentioned in the LTS upgrade guide it's not a very high priority feature.

          I'm not sure historically how the plugin has worked since I'm quite new here but for future versions of Jenkins the commands that currently check if java is installed will actually install a version of Java that isn't compatible if the version check returns a non-zero exit code.

          // TODO: parse the version number. maven-enforcer-plugin might help
          final String javaPath = node.javaPath;
          executeRemote(computer, conn, javaPath + " -fullversion", "sudo yum install -y java-1.8.0-openjdk.x86_64", logger, listener);
          executeRemote(computer, conn, "which scp", "sudo yum install -y openssh-clients", logger, listener); 

          Geordie Rogers added a comment - I had a play around with this to see what I could do but in the end I didn't really have enough time to implement what I was after, and I also don't have much Java expereince which probably didn't help. I totally agree with you that since it's mentioned in the LTS upgrade guide it's not a very high priority feature. I'm not sure historically how the plugin has worked since I'm quite new here but for future versions of Jenkins the commands that currently check if java is installed will actually install a version of Java that isn't compatible if the version check returns a non-zero exit code. // TODO: parse the version number. maven-enforcer-plugin might help final String javaPath = node.javaPath; executeRemote(computer, conn, javaPath + " -fullversion" , "sudo yum install -y java-1.8.0-openjdk.x86_64" , logger, listener); executeRemote(computer, conn, "which scp" , "sudo yum install -y openssh-clients" , logger, listener);

          Basil Crow added a comment -

          The latter problem could at least be easily corrected by installing java-11-openjdk instead of java-1.8.0-openjdk.

          Basil Crow added a comment - The latter problem could at least be easily corrected by installing java-11-openjdk instead of java-1.8.0-openjdk .

          I'll make a pull request for that

          Geordie Rogers added a comment - I'll make a pull request for that

          I just wanted to put another update here to bump the changes I made over on GitHub that are pending review https://github.com/jenkinsci/ec2-plugin/pull/777

          I also found two possible duplicates of this improvement:

          markewaite mentioned in JENKINS-68946 that the documentation currently recommends people install Java in the init script if it isn't baked into the AMI, but doesn't seem to mention that it will attempt to install Java 11 if it can't find it.

          Init script is the shell script to be run on the newly launched EC2 instance, before Jenkins starts launching a agent agent. If the AMI doesn't have Java pre-installed, you can do this in the init script.

          If you want me to update the documentation alongside this PR to mention that the plugin will attempt to install Java, let me know

          Geordie Rogers added a comment - I just wanted to put another update here to bump the changes I made over on GitHub that are pending review https://github.com/jenkinsci/ec2-plugin/pull/777 I also found two possible duplicates of this improvement: JENKINS-68946 JENKINS-69383 markewaite mentioned in JENKINS-68946 that the documentation currently recommends people install Java in the init script if it isn't baked into the AMI, but doesn't seem to mention that it will attempt to install Java 11 if it can't find it. Init script is the shell script to be run on the newly launched EC2 instance, before Jenkins starts launching a agent agent. If the AMI doesn't have Java pre-installed, you can do this in the init script. If you want me to update the documentation alongside this PR to mention that the plugin will attempt to install Java, let me know

            jthompson Jeff Thompson
            grogersxyz Geordie Rogers
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: