WebODM stop working on macOS

WebODM doesn’t start on macOS Big Sur 11.4 (20F71) and Safari 14.1.1 (16611.2.7.1.4).

Suddenly my copy of WebODM stops working. I was using it few days ago and after update (./webodm.sh update) it just doesn’t start.
After ./webodm.sh start
The following terminal output appears:
Checking for docker… OK

Checking for git… OK

Checking for docker-compose… OK

Starting WebODM…

Using the following environment:

================================

Host: localhost

Port: 8000

Media directory: appmedia

SSL: NO

SSL key:

SSL certificate:

SSL insecure port redirect: 80

Celery Broker: redis://broker

Default Nodes: 1

================================

Make sure to issue a ./webodm.sh down if you decide to change the environment.

docker-compose -f docker-compose.yml -f docker-compose.nodeodm.yml start || docker-compose -f docker-compose.yml -f docker-compose.nodeodm.yml up --scale node-odm=1

And instead of starting WebODM it just returns to prompt.
Opening http://localhost:8000 leads to message that host was not found.
Example Docker

I was thinking that maybe Docker was corrupted or my copy of WebODM so I’ve uninstalled everything and installed it again. Effect the same.

Docker resources are set to: CPU:10, Memory: 24GB, Swap: 4GB, Disk image size: 128GB - it was working with these settings before.

Any ideas?

1 Like

Have you tried rebooting after your uninstall/reinstall?

Of course!

1 Like

When installing WebODM on other Mac, after ./webodm.sh start it begins to download components. On this machine does not. Stragne is that there is completely no error messages.

What is strange, when I will create new user and install Docker+WebODM, then it works…
Question is: how to debug the reason why WebODM doesn’t start on existing user?

1 Like

Seems that the reason was active “Use Docker Compose V2” in Docker’s experimental features. The problem is that I didn’t activate it so, maybe Docker update set this.

There should be WebODM compatibility with Docker Compose V2 or error message that it should be disabled. Without this users can be left without working WebODM.

1 Like

Really interesting! We’ll have to read up on what that changes. Granted, I’m not sure if we can realistically support Experimental Features as they are by definition unstable…

Thanks for figuring this out!

Sure, so you can just check if it is enabled and warn user about it. This will save time on both sides.

1 Like

It looks like they’re rolling it out to everyone in stages, and it is meant to be compatible with the older docker-compose python module.

Would you be willing to file an issue on their GitHub issue tracker for this, since they’re asking for reports of incompatibility?

Report made. Despite of this, there is need to check if WebODM is not using some features which will not be implemented in Compose V2: docker-compose compatibility list

1 Like

Ah, it looks like you opened an issue in our repository. I was talking about the Docker CLI repository that was linked in the documentation above, as Docker is looking to collect issue reports from end-users that are having issues with the newly rolled-out Docker Compose V2.

Could you open the issue there with them?

I have made report here: Docker Compose v2 Beta incompatible with WebODM · Issue #1905 · docker/compose-cli · GitHub
My post above was just to inform about it.

1 Like

The answer from Docker:

Root cause for this is that you rely on compose start command, expecting it fails due to missing containers to start.
Compose v2 does not rely on available compose file to run start but on actual container state. Reason for this is that this compose file might have been updated, or not be available when the command is ran vs initial setup.

Can you please clarify the use-case to run start | up? up command actually will just be equivalent to start if containers already exists and are configured according to your compose file, there’s no benefit to distinguish start command in this scenario afaict.

I’m not sure, but I think the reason we use that syntax is to ensure that all docker containers are available, installed, and updated before we actually launch. Piero would know more in that instance.

So you have ready advise to use “start” with “up” which should act as needed.

Seems that problem should be solved. I will check it and report here if it is.

1 Like