After upgrading a dataminer agent, Cube won't let you login. It says dataminer is busy upgrading.
Clearing XBAP Cache Doesn't work.
Hi Michael,
Another way is to remove the folder that is created after installing the upgrade package. The name of the folder is the same as the DataMiner upgrade package installed. This folder is created under C:Skyline DataMinerUpgradesPackages
Note that when encountering such an occurrence, it’s always good to collect the progress.log and forward it to the software team for analysis on why it got stuck. (ideally, also include an SLLogCollector package)
Also note that by design, when upgrading a cluster of DataMiner Agents, the agent through which the upgrade was launched will keep showing “busy upgrading” until all of the agents in the cluster have completed the upgrade.
I had a similar problem upgrading from 9.6.0.0 to 10.0.4.0 version, and progress.log indicated that the upgrade is completed. However the cube is stuck with the message of 'upgrade is in progress'.
Initially the logs complained about the licensing files, however after updating the license files, all logs indicated the DMA is started successfully but the cube continued to complain about the upgrade being in progress.
In my case, renaming the progress.log didn't make any difference, however deleting the old packages from C:\Skyline DataMiner\Upgrades\Packages did resolve the issue with the cube.
After this, logs still indicated that the upgrade failed but the DMA is fully accessible now. It looks like DataMiner was trying to upgrade multiple times using the different IP's in my DMS.xml, but I am not certain about it.
----
192.168.x.x|2021-04-29 17:27:09|information|Sleeping 5s
192.168.x.x|2021-04-29 17:27:17|information|[SUCCEEDED] Start Service slnet
192.168.x.x|2021-04-29 17:27:17|information|Sleeping 5s
192.168.x.x|2021-04-29 17:27:25|information|[SUCCEEDED] Start Service slwatchdog
10.x.x.x|2021-04-29 17:27:27|progress|Starting up (0%)
192.168.x.x|2021-04-29 17:27:28|information|[SUCCEEDED] Start Service sldataminer
192.168.x.x|2021-04-29 17:27:28|information|[Finished]
192.168.x.x|2021-04-29 17:27:28|information|SLReplaceLauncher finished
10.x.x.x|2021-04-29 17:44:12|progress|Starting up (99%)
192.168.x.y|2021-05-04 09:06:04|progress|Starting up (0%)
192.168.x.y|2021-05-04 11:27:45|progress|Starting up (0%)
192.168.x.x|2021-05-04 12:12:52|progress|Starting up (0%)
192.168.x.x|2021-05-04 12:18:22|progress|Starting up (0%)
192.168.x.x|2021-05-04 12:34:15|progress|Starting up (0%)
192.168.x.x|2021-05-04 12:42:34|progress|Starting up (0%)
192.168.x.x|2021-05-04 14:29:15|progress|Starting up (0%)
192.168.x.x|2021-05-04 14:29:46|progress|Starting up (80%)
192.168.x.x|2021-05-04 14:30:11|progress|Starting up (100%)
192.168.x.x|2021-05-04 16:40:04|error|Multiple upgrades were marked as Executing at the same time.
## 2021-05-04 16:40:04 ## status=Failed
## 2021-05-04 16:40:05 ## allCompleted=true
192.168.x.x|2021-05-04 16:40:05|information|Failed agents: 100.x.x.x;10.x.x.x;10.x.x.x;10.x.x.x
192.168.x.y|2021-05-04 16:40:05|all_complete|Upgrade completed (failure)
General|2021-05-04 16:40:05|cluster_complete|Upgrade completed on all specified agents (within cluster) [failed for 100.x.x.x;10.x.x.x;10.x.x.x;10.x.x.x]
----
bumping this report as I had the issue today on a freshly new install with the following history revisions (on 2 servers at the same time).
10.0.0.0 -> 10.2.0.0 -> 10.2.10.0 -> 10.3.0.0-12932-20230419 release (here problem occured)
moving or deleting the files and a restart fixed the issue here as well
Have seen this a few times over the years and again today, renaming the “progress” log file in the Upgrade Package Folder and restarting Cube usually fixes it.
This can be fixed by renaming the “progress” log file in the Upgrade Package Folder and restarting Cube. The error occurs when for some reason the upgrade log file doesn’t get completed correctly and cube thinks it is still in progress.