-
Bug
-
Resolution: Unresolved
-
Medium (View bug fix roadmap)
-
None
-
6.1.4
-
6.01
-
60
-
Severity 2 - Major
-
10
-
Summary
Enabling and installing JIRA Agile; or updating JIRA Agile in a certain way is causing it to fail.
Steps to Reproduce
Install JIRA Agile in the specific order that makes it not work, which is still to be discovered.
Expected Results
JIRA Agile enables successfully.
Actual Results
The following stack trace is thrown:
2013-12-08 18:18:36,903 pool-15-thread-1 INFO hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [atlassian.plugin.util.WaitUntil] Plugins that have yet to be enabled: [com.pyxis.greenhopper.jira], 2 seconds remaining 2013-12-08 18:18:37,903 pool-15-thread-1 INFO hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [atlassian.plugin.util.WaitUntil] Plugins that have yet to be enabled: [com.pyxis.greenhopper.jira], 1 seconds remaining 2013-12-08 18:18:38,903 pool-15-thread-1 INFO hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [atlassian.plugin.util.WaitUntil] Plugins that have yet to be enabled: [com.pyxis.greenhopper.jira], 0 seconds remaining 2013-12-08 18:18:39,903 pool-15-thread-1 INFO hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Disabling com.pyxis.greenhopper.jira 2013-12-08 18:18:40,872 pool-15-thread-1 ERROR hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [atlassian.plugin.manager.PluginEnabler] Unable to start the following plugins due to timeout while waiting for plugin to enable: com.pyxis.greenhopper.jira 2013-12-08 18:18:41,872 ThreadPoolAsyncTaskExecutor::Thread 39 ERROR hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [internal.dependencies.startup.DependencyWaiterApplicationContextExecutor] Unable to create application context for [com.pyxis.greenhopper.jira], unsatisfied dependencies: none java.lang.IllegalStateException: Invalid BundleContext. at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:365) at org.apache.felix.framework.BundleContextImpl.getServiceReferences(BundleContextImpl.java:307) at org.springframework.osgi.util.OsgiServiceReferenceUtils.getServiceReferences(OsgiServiceReferenceUtils.java:159) at org.springframework.osgi.util.OsgiServiceReferenceUtils.getServiceReferences(OsgiServiceReferenceUtils.java:195) at org.springframework.osgi.util.OsgiServiceReferenceUtils.isServicePresent(OsgiServiceReferenceUtils.java:327) at org.springframework.osgi.extender.internal.dependencies.startup.MandatoryServiceDependency.isServicePresent(MandatoryServiceDependency.java:82) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.doFindDependencies(DependencyServiceManager.java:287) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.access$700(DependencyServiceManager.java:40) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager$1.run(DependencyServiceManager.java:213) at org.springframework.osgi.extender.internal.util.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:124) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:209) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:239) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175) at org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 2013-12-08 18:18:41,872 ThreadPoolAsyncTaskExecutor::Thread 39 ERROR hhunfeld 1095x47194x1 1p0no84 172.20.2.134 /rest/plugins/self-update/1.0/ [extender.internal.activator.ContextLoaderListener] Application context refresh failed (NonValidatingOsgiBundleXmlApplicationContext(bundle=com.pyxis.greenhopper.jira, config=osgibundle:/META-INF/spring/*.xml)) java.lang.IllegalStateException: Invalid BundleContext. at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:365) at org.apache.felix.framework.BundleContextImpl.getServiceReferences(BundleContextImpl.java:307) at org.springframework.osgi.util.OsgiServiceReferenceUtils.getServiceReferences(OsgiServiceReferenceUtils.java:159) at org.springframework.osgi.util.OsgiServiceReferenceUtils.getServiceReferences(OsgiServiceReferenceUtils.java:195) at org.springframework.osgi.util.OsgiServiceReferenceUtils.isServicePresent(OsgiServiceReferenceUtils.java:327) at org.springframework.osgi.extender.internal.dependencies.startup.MandatoryServiceDependency.isServicePresent(MandatoryServiceDependency.java:82) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.doFindDependencies(DependencyServiceManager.java:287) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.access$700(DependencyServiceManager.java:40) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager$1.run(DependencyServiceManager.java:213) at org.springframework.osgi.extender.internal.util.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:124) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:209) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:239) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175) at org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
Once JAG is disabled or stalled, all boards are disabled.
Workaround
- Increase the plugin start timeout from default 60 seconds to 300 seconds by specifying the startup parameter -Datlassian.plugins.enable.wait=300. For a better description please see the Workaround on JIRA System Plugin Timeout While Waiting for Plugins to Enable. Note that if you do not specify the increased timeout, you will likely run into the same problem when you try updating the plugin to a newer version in UPM.
- Restart JIRA. This should enable back JIRA Agile
- If JIRA Agile boards are missing, perform a re-index to bring back all the missing board.
So far Atlassian still unable to reproduce this behaviour explicitly, this bug ticket is created to keep track how many users are affected and find a common pattern to reproduce the bug.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWSERVER-10168] JIRA Agile fails to enable due to Invalid BundleContext
Why would I suddenly start getting this error when Jira Agile has been installed automatically for quite some time?
We have the same problem after upgrading from Core and Agile 7.2.x to 7.3.6.
The workaround from this article worked for me: https://confluence.atlassian.com/jirakb/jira-applications-system-plugin-timeout-while-waiting-for-add-ons-to-enable-212173447.html
It is possible to increase the plugin timeout period by adding the -Datlassian.plugins.enable.wait=300 argument to the JIRA application startup arguments, as in Setting Properties and Options on Startup.
Upgraded from JIRA Core 7.3.1 to 7.3.5 and suddenly have this happening. Not sure whether this has the same cause as in the other cases as we're talking about very different versions.
I can provide the log upon request.
We have this symptom after importing the data as part of a rehost of JIRA 6.4.13 from RHEL5/mysql to WS2016/postgresql. After importing the data, JIRA Agile seems to start in the log files, but the web interface reports that JIRA Agile is not running.
The log file scanner did take us to this page as a result of these messages in our log:
2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'greenhopper-launcher': org.springframework.osgi.service.ServiceUnavailableException: service matching filter=[(objectClass=com.atlassian.sal.api.scheduling.PluginScheduler)] unavailable 2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'licenseEventListener': java.lang.IllegalStateException: Invalid BundleContext. 2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'lexoRankBalancingService': java.lang.IllegalStateException: Invalid BundleContext.
I'm not certain we are actually experiencing the problem originally described. We made more than a few mistakes in our first effort at this rehost. However, I provided this data point, in case it helps. In my time, I've chased "hard-to-reproduce" scenarios before, and real data can be helpful.
Miles Duke
added a comment - - edited We have this symptom after importing the data as part of a rehost of JIRA 6.4.13 from RHEL5/mysql to WS2016/postgresql. After importing the data, JIRA Agile seems to start in the log files, but the web interface reports that JIRA Agile is not running.
The log file scanner did take us to this page as a result of these messages in our log:
2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'greenhopper-launcher': org.springframework.osgi.service.ServiceUnavailableException: service matching filter=[(objectClass=com.atlassian.sal.api.scheduling.PluginScheduler)] unavailable
2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'licenseEventListener': java.lang.IllegalStateException: Invalid BundleContext.
2017-02-28 15:27:09,411 Timer-1 WARN [springframework.context.annotation.CommonAnnotationBeanPostProcessor] Invocation of destroy method failed on bean with name 'lexoRankBalancingService': java.lang.IllegalStateException: Invalid BundleContext.
I'm not certain we are actually experiencing the problem originally described. We made more than a few mistakes in our first effort at this rehost. However, I provided this data point, in case it helps. In my time, I've chased "hard-to-reproduce" scenarios before, and real data can be helpful. A major upgrade of UPM independent of a JIRA upgrade was the cause for us, like with Marc in Nov 2015.
We were on 4, and have since upgraded to 7.
Hi everyone,
This issue has been open for 3 years. The steps to reproduce has not yet been improved since then. If they are known to anyone who watches the issue, please let us know.
Before that we are not able to start fixing this. I'll be keeping this open in the current state with a hope to get clarification here. I'll revisit the issue in some time to see if problem still exists.
Thanks!
–
Cheers,
Ignat
JIRA Bugmaster.
Our symptoms: Jira Agile disabled itself when the UPM was upgraded from 2.20.7 to 2.21 UPM.
Tried restarting JIRA with no changes ... no luck, JIRA Agile plug-in did not restart.
Restarted JIRA with the "-Datlassian.plugins.enable.wait=300" argument added to setenv.sh file and the JIRA Agile plug-in successfully started.
Jira: 6.4.5
UPM: 2.20.7 > 2.21
Agile: 6.7.14
Daniel Nuñez
added a comment - You are wrong As a follow-up to my previous comment, the workaround listed works perfectly in my environment. It seems the plug in needed approx 100 seconds to enable, but works as before once given enough time to enable.
Same symptoms - Jira Agile disabled itself when I upgraded the UPM - Jira Agile was outdated, upgraded it to latest version - still did not want to enable. Re-indexed jira, made no difference.
Jira: 6.4.11
UPM: 2.20.4
Agile: 6.7.11
Jira Agile disabled itself when i upgraded UPM (to version 2.20.1) and then trying to enable it again i had the above issue.
Jira: 6.3.15
Agile: 6.7.4
Robert Janssen
added a comment - Issue occurred after plugin Greenhopper update to Agile update without updating UPM.
Update to UPM allowed Agile Install to complete, but Agile will not Enable successfully.
Robert Janssen
added a comment - Issue occurred after plugin Greenhopper update to Agile update without updating UPM.
Update to UPM allowed Agile Install to complete, but Agile will not Enable successfully. I'm seeing the same issue as Mike, but the UPM upgrade was completed yesterday. The Agile plugin disabled itself...seemingly arbitrarily, approximately 18 hours later.
Jira Agile disabled itself when i upgraded Atlassian Universal Plugin Manager and then trying to enable it again i had the above issue.
Jira: 6.4.5
Agile: 6.7.11
I faced the same issue after upgrading to the latest JIRA Agile :
2015-06-08 13:54:20,308 ThreadPoolAsyncTaskExecutor::Thread 46 ERROR abdul 832x158785x1 14qtw6t 82.132.226.244,52.17.239.5 /rest/plugins/1.0/com.pyxis.greenhopper.jira-key [extender.internal.activator.ContextLoaderListener] Application context refresh failed (NonValidatingOsgiBundleXmlApplicationContext(bundle=com.pyxis.greenhopper.jira, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from URL [bundle://190.0:0/META-INF/spring/spring.xml]; nested exception is java.lang.IllegalStateException: Invalid BundleContext.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:420)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149)
at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:164)
at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:136)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:123)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:422)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$800(AbstractDelegatedExecutionApplicationContext.java:69)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$3.run(AbstractDelegatedExecutionApplicationContext.java:269)
at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.startRefresh(AbstractDelegatedExecutionApplicationContext.java:247)
at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:214)
at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:169)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
at org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:716)
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:745)
Caused by: java.lang.IllegalStateException: Invalid BundleContext.
at org.apache.felix.framework.BundleContextImpl.checkValidity(BundleContextImpl.java:365)
at org.apache.felix.framework.BundleContextImpl.getServiceReference(BundleContextImpl.java:256)
at org.springframework.osgi.io.internal.resolver.PackageAdminResolver$1.run(PackageAdminResolver.java:178)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.osgi.io.internal.resolver.PackageAdminResolver.getPackageAdmin(PackageAdminResolver.java:175)
at org.springframework.osgi.io.OsgiBundleResourcePatternResolver.findClassPathMatchingResources(OsgiBundleResourcePatternResolver.java:229)
at org.springframework.osgi.io.OsgiBundleResourcePatternResolver.findResources(OsgiBundleResourcePatternResolver.java:165)
at org.springframework.osgi.io.OsgiBundleResourcePatternResolver.getResources(OsgiBundleResourcePatternResolver.java:197)
at org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.getResources(AbstractOsgiBundleApplicationContext.java:425)
at org.springframework.context.annotation.ClassPathScanningCandidateComponentProvider.findCandidateComponents(ClassPathScanningCandidateComponentProvider.java:182)
at org.springframework.context.annotation.ClassPathBeanDefinitionScanner.doScan(ClassPathBeanDefinitionScanner.java:201)
at org.springframework.context.annotation.ComponentScanBeanDefinitionParser.parse(ComponentScanBeanDefinitionParser.java:84)
at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:507)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:398)
... 20 more
Using :
JIRA : v6.3.15
Upgraded to JIRA Agile : 6.7.4
Same happened with us. Test environment went fine, production environment got bugged. :/
Just a heads-up: After the plugin update, Jira prompted to re-index. Don't do this with the plugin disabled. First apply the workaround, then re-index. 
Support migros.ch
added a comment - Increasing the plugin start timeout from default 60 seconds to 300 seconds by specifying the startup parameter -Datlassian.plugins.enable.wait=300 helped! Thank you.
But shouldn't this problem be fixed in the Add-on itself? We had a Jira-Upgrad a couple of weeks ago and the same problem apeared again because the timeout settings have been resetted to 60 sec... no good.
Support migros.ch
added a comment - Increasing the plugin start timeout from default 60 seconds to 300 seconds by specifying the startup parameter -Datlassian.plugins.enable.wait=300 helped! Thank you.
But shouldn't this problem be fixed in the Add-on itself? We had a Jira-Upgrad a couple of weeks ago and the same problem apeared again because the timeout settings have been resetted to 60 sec... no good. Support migros.ch
added a comment - We have the same Problem here. Will try this and give feedback. 
Alicia Pena
added a comment - I just updated Jira Agile plugin again last night from version 6.6.0 to version 6.6.13 on our Jira version 6.3.7#6337 and the jira agile plugin became completely disabled. I Shut down jira, implemented the -Datlassian.plugins.enable.wait=300, restarted Jira, and everything came back.
Alicia Pena
added a comment - I just updated Jira Agile plugin again last night from version 6.6.0 to version 6.6.13 on our Jira version 6.3.7#6337 and the jira agile plugin became completely disabled. I Shut down jira, implemented the -Datlassian.plugins.enable.wait=300, restarted Jira, and everything came back. We had that error message after upgrading JIRA Agile from 6.6.0 to 6.6.11 on a JIRA 6.1.7 with UPM v2.18.1
Alicia Pena
added a comment - I was affected by this when I updated the Atlassian Universal Plugin Manager. I simply shut down the application and restarted it and everything was back to normal.
Alicia Pena
added a comment - I was affected by this when I updated the Atlassian Universal Plugin Manager. I simply shut down the application and restarted it and everything was back to normal. After opening a support ticket, it was determined that our problem was caused by having a duplicate Rank customfield (see GHS-10985) from a failed upgrade. A couple of weeks ago, while we were troubleshooting a different issue, we attempted to upgrade Agile from 6.3.9.2 to 6.5. The upgrade failed. Without a time-stamp for when the field was created, we can't be 100% certain that it came from the failed upgrade, but we couldn't find any other reason that would have caused it to show up.
I do not know if the problem stated here is related, but it is certainly possible.
In our test environment, we installed agile 6.3.9.2 in July. Removed and re-installed agile 6.3.12 last week. Today was trying to upgrade to agile version 6.6 through the UI and received this error. Successfully installed in 4 other test instances, none of which have anywhere close to the amount of data. Did have one other occurrence when the countdown was down to 22 seconds remaining. Using Jira version 6.1.6.
+1 for affected. We also experienced a failure when initially trying to update UPM.
We were able to recover from this at runtime by re-enabling the JIRA Agile plugin via the admin GUI.
I believe it triggered as part of a scheduled restart of JIRA, which we do daily to ensure a consistent backup.
Roman Serazhiev (Inactive)
added a comment - Happened to me today.
Upgraded from JIRA 6.0.3 to JIRA 6.2.1 using manual (zip) method.
After JIRA was upgraded, I have upgraded UPM, and started to upgrade all other plugins.
JIRA capture downloaded the upgrade file, said that it is installing and then gave me "failed to be enabled, please see the logs" message.
Fixed by restarting JIRA service
Roman Serazhiev (Inactive)
added a comment - Happened to me today.
Upgraded from JIRA 6.0.3 to JIRA 6.2.1 using manual (zip) method.
After JIRA was upgraded, I have upgraded UPM, and started to upgrade all other plugins.
JIRA capture downloaded the upgrade file, said that it is installing and then gave me "failed to be enabled, please see the logs" message.
Fixed by restarting JIRA service 
Svein Seldal
added a comment - We got this now after a failed UPM update. Running Jira 6.2 and UPM 2.15.1. I'm here because we've apparently lost Jira Agile!
Svein Seldal
added a comment - We got this now after a failed UPM update. Running Jira 6.2 and UPM 2.15.1. I'm here because we've apparently lost Jira Agile! 
Ilya Fourmanov
added a comment - We were also affected, it may be related to UPM update.
Found this ticket through log scanner, thanks Hercules!
Ilya Fourmanov
added a comment - We were also affected, it may be related to UPM update.
Found this ticket through log scanner, thanks Hercules!
9.1.0... starts after few reboots