Build server error & unknown error closing files

I tried running a deployment but couldn’t get it to work.

At first, the OttoFMS web portal wasn’t responsive and OttoDeploy wasn’t able to schedule the deployment. After restarting the Otto service on the prod server, I was able to schedule the deployment, but once it ran, it failed with “Build server timeout: Timeout exceeded”

Then I restarted the Otto service on the dev server and re-ran the deployment. It failed with “Build server error. http Status: 409. FMS Error 18000: build already in progress”.

Then I restarted both servers and reran the deployment, and it failed with “Error closing files: unknown error”.

I’m running OttoFMS 4.7.2 and FMS 21.0.2.202 on Windows Server 2022 Datacenter. The prod server is an m6i.2xlarge EC2 instance.

Here are the Otto and OttoFMS logs from the prod server:
ottofms-logs.zip (70.9 KB)
otto-logs.zip (6.3 KB)

Lmk if you need anything else from me.

Hi Mislav,

Is this on one of your Soliant servers?

If so then this is a known issue. Currently Soliant-hosted servers default setup is incompatible with OttoFMS. We’re actively working on solutions to enable Soliant servers to run OttoFMS smoothly. If your server needs immediate attention, please note that the Soliant hosting team is aware of these challenges and is currently the only party capable of resolving them.

Todd

1 Like

+1 for the Soliant issue - we’re still waiting on getting a fix to get OttoFMS reliable on Soliant.cloud hosting.

Hi Todd, thanks for your response. Yes, it’s on a Soliant.cloud hosted server.

Over the past few weeks, we had been seeing a different issue where restarting the Otto service would allow the deployment to run. That’s the issue that our hosting team is aware of. What I was describing is new behavior after installing OttoFMS 4.7.2 where the deployment does not run even after restarting it. But of course it could be tied to the same underlying root cause.

Thanks for the clarification. I suspect that it is the same root cause.

Todd

This issue appears to be resolved for me in v 4.8.0. Great work, this makes my life a whole lot easier again!

1 Like

Hi, sorry to resurrect this one, but I may have gotten over excited with thinking this is resolved. I’m still seeing this in our Soliant hosted servers, even when running 4.8.0

Things seem to work absolutely fine for an hour or so after restarting the Otto service, and then things stop working, and the logs (info and error) are full of this:

I then have to restart the service, and it comes good for another hour or so.

Other things I’ve noticed is that Offsite Backup schedules configured in OttoFMS get lost after a crash.

Any ideas? Happy to provide any kind of log information you guys want…

Hi James,

I am sorry. I am sure it is frustrating to get your hopes up, only to have them dashed again and again.

We know exactly what the problem is. There is nothing we can easily do about it.

OttoFMS requires that you have the user name and password that is defined in the Admin Console. This is the one you set when you run the installer.

You can’t use an External Authentication username and password, because there is a long standing FileMaker bug, that causes the fmsadmin tool to fail randomly with those credentials. It will work for a time and then fail, and then work again.

Soliant gives you an External Auth defined user name and password. Not the admin console credentials.

Until Soliant changes their policy and gives you the admin console credentials or FileMaker fixes the bug, you will not be able to reliably run OttoFMS on Soliant servers.

We have communicated everything we know about the problem to Soliant’s team. I don’t know what if anything they are planning to do about it.

I wish I had better news.

Good luck and Happy Holidays

Todd

1 Like

Hi Todd,

Thanks so much for continuing to investigate. The Soliant guys have been in touch, and we’re going to try something with them. I’ll keep you posted on any updates.

All the best to you and the team,

James.