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

NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Not A Defect
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      During restart when upgrading Jenkins (core) from 2.111 => 2.112

      2018-03-20 07:50:39 WARNING [hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error]   Failed to instantiate Key[type=hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl, an
      notation=[none]]; skipping this component
      com.google.inject.ProvisionException: Unable to provision, see the following errors:
      
      1) Error injecting constructor, java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
        at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl.<init>(SSHLauncher.java:1617)
      
      1 error
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
              at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
              at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
              at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
              at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
              at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
              at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
              at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
              at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:482)
              at hudson.ExtensionList.load(ExtensionList.java:366)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.getComponents(ExtensionList.java:169)
              at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:192)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.iterator(ExtensionList.java:158)
              at org.jenkinsci.plugins.xunit.AliasInitializer.addAliases(AliasInitializer.java:47)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:498)
              at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
              at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
              at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
              at jenkins.model.Jenkins$5.runTask(Jenkins.java:1064)
              at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
              at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
              at java.lang.Thread.run(Thread.java:748)
      Caused by: java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
              at java.lang.Class.getDeclaredMethods0(Native Method)
              at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
              at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
              at java.lang.Class.getMethod0(Class.java:3018)
              at java.lang.Class.getMethod(Class.java:1784)
              at hudson.model.Descriptor.<init>(Descriptor.java:289)
              at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl.<init>(SSHLauncher.java:1617)
              at hudson.plugins.sshslaves.SSHLauncher$DescriptorImpl$$FastClassByGuice$$7821d6d6.newInstance(<generated>)
              at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
              at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
              at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
              at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
              at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
              ... 29 more
      Caused by: java.lang.ClassNotFoundException: hudson.tools.JDKInstaller$FileSystem
              at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
              at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
              at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
              ... 45 more
      
      2018-03-20 07:50:39 WARNING [hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1 error]   Failed to instantiate Key[type=hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl, annotation=[none]]; skipping this component
      com.google.inject.ProvisionException: Unable to provision, see the following errors:
      
      1) Error injecting constructor, java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
        at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl.<init>(ManagedWindowsServiceLauncher.java:540)
      
      1 error
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
              at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
              at hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
              at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
              at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
              at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
              at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
              at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
              at hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:482)
              at hudson.ExtensionList.load(ExtensionList.java:366)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.getComponents(ExtensionList.java:169)
              at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:192)
              at hudson.ExtensionList.ensureLoaded(ExtensionList.java:304)
              at hudson.ExtensionList.iterator(ExtensionList.java:158)
              at org.jenkinsci.plugins.xunit.AliasInitializer.addAliases(AliasInitializer.java:47)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
              at java.lang.reflect.Method.invoke(Method.java:498)
              at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
              at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
              at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
              at jenkins.model.Jenkins$5.runTask(Jenkins.java:1064)
              at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
              at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
              at java.lang.Thread.run(Thread.java:748)
      Caused by: java.lang.NoClassDefFoundError: hudson/tools/JDKInstaller$FileSystem
              at java.lang.Class.getDeclaredMethods0(Native Method)
              at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
              at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
              at java.lang.Class.getMethod0(Class.java:3018)
              at java.lang.Class.getMethod(Class.java:1784)
              at hudson.model.Descriptor.<init>(Descriptor.java:289)
              at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl.<init>(ManagedWindowsServiceLauncher.java:540)
              at hudson.os.windows.ManagedWindowsServiceLauncher$DescriptorImpl$$FastClassByGuice$$39d9fc24.newInstance(<generated>)
              at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
              at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
              at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
              at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
              at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
              at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
              at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
              ... 29 more
      Caused by: java.lang.ClassNotFoundException: hudson.tools.JDKInstaller$FileSystem
              at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1374)
              at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1327)
              at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1080)
              at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
              ... 45 more
      

        Attachments

          Issue Links

            Activity

            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            Reinhold Füreder Ah, the following step breaks the upgrade detection:

            3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files

            Maybe you were manually updating jenkins.install.InstallUtil.lastExecVersion because before JENKINS-48365 was fixed in 2.96 that file was not updated correctly after an upgrade. You should not update it manually any more. Jenkins will upgrade the file itself after starting and detecting that an upgrade occured.

            I am not sure why you are updating jenkins.install.UpgradeWizard.state manually, but that might also break the upgrade logic. What was your reason for manually changing that file?

            I think if you just remove step 3 in your process upgrades should work correctly in the future.

            Show
            dnusbaum Devin Nusbaum added a comment - - edited Reinhold Füreder Ah, the following step breaks the upgrade detection: 3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files Maybe you were manually updating jenkins.install.InstallUtil.lastExecVersion because before JENKINS-48365 was fixed in 2.96 that file was not updated correctly after an upgrade. You should not update it manually any more. Jenkins will upgrade the file itself after starting and detecting that an upgrade occured. I am not sure why you are updating jenkins.install.UpgradeWizard.state manually, but that might also break the upgrade logic. What was your reason for manually changing that file? I think if you just remove step 3 in your process upgrades should work correctly in the future.
            Hide
            reinholdfuereder Reinhold Füreder added a comment -

            Devin Nusbaum Thanks for your investigations and the hint. According to the SVN history we added that (updating both files) at the end of 2016 to "Skip jenkins setup wizard by creating files with curr version". (I must admit that I cannot remember the exact details anymore, but will try your suggestion...)

            Show
            reinholdfuereder Reinhold Füreder added a comment - Devin Nusbaum Thanks for your investigations and the hint. According to the SVN history we added that (updating both files) at the end of 2016 to "Skip jenkins setup wizard by creating files with curr version". (I must admit that I cannot remember the exact details anymore, but will try your suggestion...)
            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            Reinhold Füreder I think that the setup wizard should be skipped automatically on upgrades in nearly all cases, but maybe the faulty upgrade detection logic was causing it to show up repeatedly. If you are still seeing the setup wizard on upgrades, then you can try passing -Djenkins.install.runSetupWizard=false to Java when starting Jenkins, which is a better way to disable the setup wizard without changing the initialization sequence. (Note: Don't do this if you are using the same code to create new instances of Jenkins (non-upgrades) unless the machine is offline/inaccessible because they will be completely insecure by default.)

            Show
            dnusbaum Devin Nusbaum added a comment - - edited Reinhold Füreder I think that the setup wizard should be skipped automatically on upgrades in nearly all cases, but maybe the faulty upgrade detection logic was causing it to show up repeatedly. If you are still seeing the setup wizard on upgrades, then you can try passing -Djenkins.install.runSetupWizard=false to Java when starting Jenkins, which is a better way to disable the setup wizard without changing the initialization sequence. (Note: Don't do this if you are using the same code to create new instances of Jenkins (non-upgrades) unless the machine is offline/inaccessible because they will be completely insecure by default.)
            Hide
            reinholdfuereder Reinhold Füreder added a comment -

            Devin Nusbaum OK, I have now tried and tested your advice (partially) and thus removed "Update 'jenkins.install.InstallUtil.lastExecVersion' file" (part of step #3; i.e. still updating 'jenkins.install.UpgradeWizard.state' file) => and it works fine:

            1. It nicely logs the Jenkins upgrading (which was missing completely before and is a really good thing to have in the logs; both middle lines are new):
              2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained]   Started initialization
              2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins]   Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112.
              2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins]   Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): []
              2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained]   Listed all plugins
              
            2. Also the 'jenkins.install.InstallUtil.lastExecVersion' file is written correctly by Jenkins
            3. And when not having the new JDK Tool plugin installed and upgrading from version 2.111 to 2.112 it correctly auto-installs it:
              2018-03-21 11:47:34 INFO [jenkins.InitReactorRunner$1 onAttained]   Started initialization
              2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins]   Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112.
              2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins]   Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [jdk-tool.hpi]
              2018-03-21 11:47:35 INFO [jenkins.InitReactorRunner$1 onAttained]   Listed all plugins
              

            => Thanks again for your help!

            There are just two minor glitches or things that could be improved:

            1. The JDK Tool plugin is auto-installed "only" in (initial release) version 1.0 – why not version 1.1 that is already available? (In the plugin manager the update to version 1.1 is correctly shown as available, so it is no big problem; not sure if it might be possible that the latest version might be needed for whatever reason – or is the minimum required version of JDK Tool plugin explicitly specified as 1.0?)
            2. Logging of Jenkins version downgrading is missing – which of course should not be a normal/regular thing to do anyhow (I am not sure if I have ever needed/did it, except for testing this issue): however, assuming it is very easy to do, why not log it out, and maybe even with level WARNING (because it is unusual or not recommended)?
            Show
            reinholdfuereder Reinhold Füreder added a comment - Devin Nusbaum OK, I have now tried and tested your advice (partially) and thus removed "Update 'jenkins.install.InstallUtil.lastExecVersion' file" (part of step #3; i.e. still updating 'jenkins.install.UpgradeWizard.state' file ) => and it works fine: It nicely logs the Jenkins upgrading (which was missing completely before and is a really good thing to have in the logs; both middle lines are new): 2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained] Started initialization 2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins] Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112. 2018-03-21 11:17:41 INFO [hudson.PluginManager loadDetachedPlugins] Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [] 2018-03-21 11:17:41 INFO [jenkins.InitReactorRunner$1 onAttained] Listed all plugins Also the 'jenkins.install.InstallUtil.lastExecVersion' file is written correctly by Jenkins And when not having the new JDK Tool plugin installed and upgrading from version 2.111 to 2.112 it correctly auto-installs it: 2018-03-21 11:47:34 INFO [jenkins.InitReactorRunner$1 onAttained] Started initialization 2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins] Upgrading Jenkins. The last running version was 2.111. This Jenkins is version 2.112. 2018-03-21 11:47:35 INFO [hudson.PluginManager loadDetachedPlugins] Upgraded Jenkins from version 2.111 to version 2.112. Loaded detached plugins (and dependencies): [jdk-tool.hpi] 2018-03-21 11:47:35 INFO [jenkins.InitReactorRunner$1 onAttained] Listed all plugins => Thanks again for your help! There are just two minor glitches or things that could be improved: The JDK Tool plugin is auto-installed "only" in (initial release) version 1.0 – why not version 1.1 that is already available? (In the plugin manager the update to version 1.1 is correctly shown as available, so it is no big problem; not sure if it might be possible that the latest version might be needed for whatever reason – or is the minimum required version of JDK Tool plugin explicitly specified as 1.0?) Logging of Jenkins version downgrading is missing – which of course should not be a normal/regular thing to do anyhow (I am not sure if I have ever needed/did it, except for testing this issue): however, assuming it is very easy to do, why not log it out, and maybe even with level WARNING (because it is unusual or not recommended)?
            Hide
            dnusbaum Devin Nusbaum added a comment -

            Glad to hear that everything is working!

            why not version 1.1 that is already available?

            Plugins like this that have been split from core are explicitly bundled in the war file and listed in split-plugins.txt to enable the automatic installation. jdk-tool:1.0 had to be released before Jenkins 2.112 was released, so it depends on Jenkins 2.111. This means that there is a short time where a 2.111 user could install the plugin and have multiple instances of the same class on the classpath, which is bad, so once Jenkins 2.112 was released, I updated jdk-tool to depend on Jenkins 2.112 and released 1.1, so that 1.0 is no longer available from the update center for 2.111 users. There is no issue with bundling 1.0 or 1.1 in core, but if later releases of jdk-tool have significant changes, such as adding new dependencies, we would probably not want to make those versions be bundled in Jenkins core, so it's easiest to just leave 1.0 as the bundled version, and let people upgrade naturally through the update center.

            Logging of Jenkins version downgrading is missing

            I'm not sure offhand, but feel free to open a new issue requesting that logging be added (or a pull request to https://github.com/jenkinsci/jenkins, I think the right place would be this method).

            Show
            dnusbaum Devin Nusbaum added a comment - Glad to hear that everything is working! why not version 1.1 that is already available? Plugins like this that have been split from core are explicitly bundled in the war file and listed in split-plugins.txt to enable the automatic installation. jdk-tool:1.0 had to be released before Jenkins 2.112 was released, so it depends on Jenkins 2.111. This means that there is a short time where a 2.111 user could install the plugin and have multiple instances of the same class on the classpath, which is bad, so once Jenkins 2.112 was released, I updated jdk-tool to depend on Jenkins 2.112 and released 1.1, so that 1.0 is no longer available from the update center for 2.111 users. There is no issue with bundling 1.0 or 1.1 in core, but if later releases of jdk-tool have significant changes, such as adding new dependencies, we would probably not want to make those versions be bundled in Jenkins core, so it's easiest to just leave 1.0 as the bundled version, and let people upgrade naturally through the update center. Logging of Jenkins version downgrading is missing I'm not sure offhand, but feel free to open a new issue requesting that logging be added (or a pull request to https://github.com/jenkinsci/jenkins , I think the right place would be this method ).

              People

              • Assignee:
                dnusbaum Devin Nusbaum
                Reporter:
                reinholdfuereder Reinhold Füreder
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: