[JIRA] (JENKINS-50272) NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112

832 views
Skip to first unread message

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:05:03 AM3/20/18
to jenkinsc...@googlegroups.com
Reinhold Füreder created an issue
 
Jenkins / Bug JENKINS-50272
NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112
Issue Type: Bug Bug
Assignee: Unassigned
Components: core
Created: 2018-03-20 07:04
Priority: Critical Critical
Reporter: Reinhold Füreder

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
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:08:02 AM3/20/18
to jenkinsc...@googlegroups.com

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:27:02 AM3/20/18
to jenkinsc...@googlegroups.com

Well, the solution was to also install the JDK Tool Plugin, as admittedly at least vaguely mentioned in the change log:

Install from java.sun.com installation method for JDK tools has been moved to a new JDK Tool Plugin. (issue 22367)

In my installation I was a bit lucky as this was then done implicitly when updating Jenkins plugins too: due to seemingly new dependency of the only two plugins (cloudbees-folder v6.4, credentials-binding v1.16) that were not up-to-date:

2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'cloudbees-folder' plugin...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'cloudbees-folder:6.3' plugin: 6.4...
2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Adding dependent install of jdk-tool for plugin cloudbees-folder
...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'credentials-binding' plugin...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'credentials-binding:1.15' plugin: 1.16...
2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Dependent install of jdk-tool for plugin credentials-binding already added, skipping
...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   ---> Installation of plugins in progress, waiting for completion...
2018-03-20 08:13:33 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of JDK Tool on behalf of SYSTEM
2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading JDK Tool
2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Folders on behalf of SYSTEM
2018-03-20 08:13:35 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Folders
2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Credentials Binding on behalf of SYSTEM
2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Credentials Binding
---> Plugins installed:
        cloudbees-folder:6.4
        credentials-binding:1.16

Why did this problem occur? => I am always first updating solely Jenkins core (followed by testing the update with some pipelines) and only then (in an explicit second step) update Jenkins plugins (again followed by testing the updates with some pipelines)...

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:32:11 AM3/20/18
to jenkinsc...@googlegroups.com
Reinhold Füreder edited a comment on Bug JENKINS-50272
Well, the * solution was to also install the brand-new JDK Tool Plugin * , as admittedly at least vaguely mentioned in the change log:
{quote}Install from java.sun.com installation method for JDK tools has been moved to a new JDK Tool Plugin. (issue 22367) {quote}


In my installation I was a bit lucky as this was then done implicitly when updating Jenkins plugins too: due to seemingly new dependency of the only two plugins (cloudbees-folder v6.4, credentials-binding v1.16) that were not up-to-date:
{noformat}

2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'cloudbees-folder' plugin...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'cloudbees-folder:6.3' plugin: 6.4...
2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Adding dependent install of jdk-tool for plugin cloudbees-folder
...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Checking 'credentials-binding' plugin...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   Installing update for 'credentials-binding:1.15' plugin: 1.16...
2018-03-20 08:13:32 INFO [hudson.model.UpdateSite$Plugin deploy]   Dependent install of jdk-tool for plugin credentials-binding already added, skipping
...
2018-03-20 08:13:32 INFO [java.util.logging.LogManager$RootLogger log]   ---> Installation of plugins in progress, waiting for completion...
2018-03-20 08:13:33 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of JDK Tool on behalf of SYSTEM
2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading JDK Tool
2018-03-20 08:13:34 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Folders on behalf of SYSTEM
2018-03-20 08:13:35 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Folders
2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$DownloadJob run]   Starting the installation of Credentials Binding on behalf of SYSTEM
2018-03-20 08:13:36 INFO [hudson.model.UpdateCenter$UpdateCenterConfiguration download]   Downloading Credentials Binding
---> Plugins installed:
        cloudbees-folder:6.4
        credentials-binding:1.16
{noformat}

 h6. Why did this problem occur? =>

* I am always first updating solely Jenkins core (followed by testing the update with some pipelines) and only then (in an explicit second step) update Jenkins plugins (again followed by testing the updates with some pipelines)...
* So I am not entirely happy due to being surprised by that problem, but I can certainly live with the required fix.

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:36:02 AM3/20/18
to jenkinsc...@googlegroups.com
Reinhold Füreder resolved as Won't Fix
 

I dare to resolve with "Won't Fix".

Not sure if there is a possibility to kind of signal the new need for installing a plugin (due to refactorings) to avoid this error. And of course this only hits existing installations...
Change By: Reinhold Füreder
Status: Open Resolved
Resolution: Won't Fix

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 3:40:02 AM3/20/18
to jenkinsc...@googlegroups.com
Reinhold Füreder edited a comment on Bug JENKINS-50272
I dare to resolve with "Won't Fix".

Not sure if there is a possibility to kind of signal the new need for installing a plugin (due to refactorings) to avoid this error. And of course this only hits existing installations...


Poor mans attempt to avoid this error based on change log (https://jenkins.io/changelog/ for 2.112): explicitly list all plugins that depend on the this JDK Tool plugin and that newly require the installation of JDK Tool plugin. Oh! Or is the Jenkins core depending on it already?

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 8:41:02 AM3/20/18
to jenkinsc...@googlegroups.com
Reinhold Füreder edited a comment on Bug JENKINS-50272
I dare to resolve with "Won't Fix".
Not sure if *Is there is a good possibility to kind of signal the new need for installing a plugin (due to refactorings) to avoid this error . ?* And of course this problem only hits existing installations...

 Poor mans *Suggestion for a poor man's attempt to avoid this error based on change log (https://jenkins.io/changelog/ for 2.112): explicitly * Explicitly list all plugins that depend on the this JDK Tool plugin and that newly require the installation of JDK Tool plugin. Oh! Or is the Jenkins core depending on it already?

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 10:16:02 AM3/20/18
to jenkinsc...@googlegroups.com
Devin Nusbaum assigned an issue to Devin Nusbaum
 
Change By: Devin Nusbaum
Assignee: Devin Nusbaum

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 10:16:02 AM3/20/18
to jenkinsc...@googlegroups.com
Devin Nusbaum commented on Bug JENKINS-50272
 
Re: NoClassDefFoundError "hudson/tools/JDKInstaller$FileSystem" at SSHLauncher after Jenkins Update 2.111->2.112

Reinhold Füreder The new plugin should be automatically installed on an upgrade. If it was not upgraded, that is a bug and it should be fixed.

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 10:31:03 AM3/20/18
to jenkinsc...@googlegroups.com

Devin Nusbaum Frankly, I had hoped so too (ad automatically installed). However, I am not sure whether or not my Jenkins core upgrade automation process/procedure may be disallowing that?

  1. (Manual) "Manage Jenkins > Prepare for Shutdown"
  2. (Automatic) Via Ansible:
    1. Download the specific version as debian package
    2. Install via Ansible (apt deb)
    3. Update 'jenkins.install.UpgradeWizard.state' and 'jenkins.install.InstallUtil.lastExecVersion' files
    4. Restart Jenkins

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 10:32:02 AM3/20/18
to jenkinsc...@googlegroups.com

Reinhold Füreder Can you post logs from the time of the upgrade? 

I would expect to see a line like:

Upgrading Jenkins. The last running version was $old. This Jenkins is version $new.

If you do not see such a line, then Jenkins did not detect that an upgrade was happening (possibly related to JENKINS-48365), which explains why the plugin was not installed. That shouldn't be possible when upgrading from 2.111 unless maybe your instance has no jenkins.install.lastExecVersion file?

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 10:40:01 AM3/20/18
to jenkinsc...@googlegroups.com

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 anymore, Jenkins will upgrade the file itself after starting.

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.

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 10:41:02 AM3/20/18
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-50272
[~reinholdfuereder] Ah, the following step breaks the upgrade detection:

{quote}

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

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 anymore, 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.

r.fuereder@xortex.com (JIRA)

unread,
Mar 20, 2018, 10:56:02 AM3/20/18
to jenkinsc...@googlegroups.com

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...)

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 11:15:03 AM3/20/18
to jenkinsc...@googlegroups.com

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 unless the machine is offline/inaccessible because they will be completely insecure by default.)

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 20, 2018, 1:32:02 PM3/20/18
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-50272
[~reinholdfuereder] 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.)

r.fuereder@xortex.com (JIRA)

unread,
Mar 21, 2018, 7:22:02 AM3/21/18
to jenkinsc...@googlegroups.com

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)?

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 21, 2018, 9:25:02 AM3/21/18
to jenkinsc...@googlegroups.com

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).

dbeck@cloudbees.com (JIRA)

unread,
Mar 24, 2018, 7:44:02 PM3/24/18
to jenkinsc...@googlegroups.com
Daniel Beck closed an issue as Not A Defect
 
Change By: Daniel Beck
Status: Reopened Closed
Resolution: Not A Defect

dbeck@cloudbees.com (JIRA)

unread,
Mar 24, 2018, 7:44:03 PM3/24/18
to jenkinsc...@googlegroups.com
Daniel Beck reopened an issue
Change By: Daniel Beck
Resolution: Won't Fix
Status: Resolved Reopened
Reply all
Reply to author
Forward
0 new messages