Deployment Stuck for Over 8 Hours — Unable to Abort

Hi,

The deployment using OttoFMS to one of our servers has been running for over 8 hours. I attempted to click “Abort Deployment” this morning, but it didn’t stop or cancel the process, and it’s still running.


Could you please advise how to stop the deployment and how to debug the underlying issue?

Thank you,
Angeline John

To stop the deployment you can restart OttoFMS. as for debugging the underlying issue, did you have a pre-deployment script on that deployment? It would also help if you get the Deployment Debug Information and send that along for troubleshooting.

-Kyle

  • Attached is the debug info
    Debug Logs 147.zip (6.6 KB)
  • Yes, there is a pre-deployment script that gets executed and it is stuck in that phase for over 8 hours.
  • The disk space is not being read correctly. There is more than 100GB available and the OttOFMS says that it needs 90GB but only 80GB are available.
  • Is there a particular reason for the Abort Deployment button to not work?

Depending on how the deployment is hung (which is what happened for you) the abort button can fail to work as the server is stopped while trying to do something.

For the disk space part, OttoFMS is checking only volume containing the FileMaker Default Backup location. It should match with the stats on the OttoFMS Dashboard. It looks to me like something got hung after your deployment finished and it never properly ended. It also looks like theres something funky going on with the log.

I would recommend starting by upgrading to the most recent version of OttoFMS and trying again.

-Kyle

The OttoFMS dashboard is also showing sufficient space on the Backup drive as shown below yet the log says that there was no sufficient disk space.

I have occassionally seen the post-deploy script hang and never seemingly complete. This occurs infrequently and randomly it appears. When it does, aborting the OttoFMS process works fine. The danger is when I try to abort the deployment and it decides to roll everything back (even though deployment actually worked).

Sounds like a similar thing here albeit pre-deploy script rather than post.

@weetbicks, Thanks for sharing that insight. I agree, the behavior seems random, which makes it tricky to reproduce consistently and this is the first time that I have experienced it.

It is frustrating that we cannot debug on which script step actually caused it to hang. If you have any thoughts on the same then please let me know. Thank you.