Deeming this as critical as we have several deployments that are now stalling…
I realize this has been posted several times over the past 2 years, but none of the other posts have helped.
At this point, I have deployments stalling with a message of “Cannot start this task yet because task ServerTasks-67902 (RW) is currently running…”. I do not see this task in the ServerTasks table in the database though, so it’s not like I can manually update the State to “Canceled”.
I have even attempted to create a dummy record for this ServerTask, set the State to “Cancelled”, and this did not resolve. I can though see the page though at ./app#/tasks/servertasks-67902, so I used the UI to change the State from “Canceled” to “Failed” in the hopes that the UI would update any related records to truly kill off the task, no such luck…
I have also scanned the DB for any relationship records for this ServerTask relationship, with no luck.
Please note that I believe this is probably related to an Octopus upgrade that was applied to the instance two days ago. I believe the version was upgraded from 3.17.12 to 2018.6.13 based upon the upgrade prompts the UI provided. I may be wrong though on the 3.17.12 version though as the OctopusServerInstallationHistory table shows 3.16.0 as the release prior to the 2018.* version.
Any help would be greatly appreciated. Thanks in advance!
Thanks for getting in touch, I’m sorry to hear that your deployments have stalled.
That lock is taken out per step/machine as a safety mechanism so you don’t run two interfering steps on the same machine at the same time. Are you seeing that message when deploying to a particular machine? It indicates that a step from servertasks-67902 is still running (or has stalled) on that machine. You should be able to release the lock by killing the process.
If it’s a Tentacle that is stuck restarting the Tentacle service should remedy the issue.
I had mentioned though that in the database, servertask-67902 did not actually exist in the ServerTasks table, thus I was not able to determine what the task was, nor what process or server was being updated. This is why I was looking to resolve what relationship record existed somewhere else in the DB so I could help resolve the issue.
So unfortunately the answer provided didn’t help, but the good news is that this lock seems to have lifted itself. I know for a fact that a reboot did not resolve it, but am curious if an automated re-index may have.
Thank you for the assistance. For now we can consider this resolved with an unknown root cause and resolution.