What to do when a task becomes stuck in "Cancelling" state?


My task in XL Deploy is stuck in the Cancelling state.


XL Deploy


Given that you are now unable to cancel or abort the task, you will have to use a different workaround for these. If those tasks are not important anymore, you can delete them from the XL_DEPLOY_SERVER_HOME/work directory next time you shutdown XLD server.

There should be a {taskID}.task file. If the deployment has artifact CI there should also be a .tmp folder and as the name will have the task-DATE_and_TIME.

Once you have removed them, when XLD is started up again, they should no longer appear in the task menu.


The most likely reason you would see a task in this state  (canceling but never canceled, nor able to be aborted) is that task information stored on the disc has been corrupted. The most common reason we see for this is that XLD has been stopped abruptly while a task is running. Although, it could occur if in other circumstances.


In general, you should never restart XLD server while there are active tasks. You should put the server in maintenance-mode and wait for all active tasks to be finished, or take manual actions to either stop or abort them gracefully. The best strategy, if you want to cancel a deployment task, is to first stop (gracefully stopping the task) or abort (forcefully stopping the task) and then rollback the deployment. Just pressing cancel on a partially completed deployment may result in the application not working as expected on the target server.

Additional Information

For more information, please see The Deploy Work Dir




Was this article helpful?
0 out of 0 found this helpful


  • >There should be a {taskID}.task file. If the deployment has artifact CI there should also be a .tmp folder and as name will have the task-DATE_and_TIME. Refer to our documentation here for more information.

    Is there a link to specific documentation missing from this comment? I find it unclear how to associate a .task file with any task-* directory. I understand that perhaps one could correlate the date & time in the directory name with the task start time, but this doesn't seem reliable.

    I am using XL Deploy 9.5.3.

  • Additionally, is there any documentation on how the repository, work directory and recovery.dat file are coordinated would be valuable. I haven't yet been able to locate a recovery.dat file in my installation. But I'm trying to better understand how these task files are managed.

  • Hi Adam, 

    There should have been a link for reference.  I've added it but I am afraid it is not likely to shed light on the topics you outline. 

    First, to the question of mapping a task to its artifact.  There is no data provided within either and nothing in naming conventions etc. that would allow the user to connect the two. 

    The file recovery.dat is no longer being used.  I have to be honest, I don't know why it is mentioned in the documentation.  It was a system file that is binary and not human readable.  It didn't offer anything in the way of providing a mechanism in either understand the files in the work directory or controlling them. 

    This particular article a manual approach (deletion) to handle unexpected results.  Beyond this the system manages tasks. This article discusses the, admittedly, limited actions you can take.   There is no supported way to intervene beyond what is stated here.

    Whenever possible this should be done only when XLD is in maintenance mode and all task activity has stopped. 

    There is an ongoing internal discussion around the need for improvement in this regard.   Ideally, it would be good if you could identify problematic task in the UI in task monitor.  If possible task could be aborted, stopped or failed.  Those that cannot should be able to be deleted form here and that deletion should be complete, ie it shoud clean up artifacts, task files and an other temporary file generated. 






Please sign in to leave a comment.