OpenDroneMap
ERROR: for worker UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
How did you install WebODM? (Docker, natively, ...)? Docker on CentOS 7
What's your browser and operating system? N/A
What is the problem? See below.
What should be the expected behaviour? WebODM should start without an error.
How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)
Update WebODM using ./webodm.sh update. Start WebODM using ./webodm.sh start [--no-default-node].
Issue details:
This happens every single time when starting WebODM after I update it. To get it going again I have to keep running the update over and over, even though it isn't applying new updates (though it does remove the containers). After all of the attempts, when it does start successfully, it always starts fine after that (such as following a reboot).
Load is basically zero during startup, CPU is idle, disk read is very low, iowait is zero, network is zero, I'm not using any network shares - I just don't understand why it behaves this way.
Also the error at the bottom suggests a 60 second timeout. In reality it borks after about 10 seconds (though I haven't timed it exactly). It's nowhere near 60 seconds though.
[root@survey WebODM]# ./webodm.sh start --no-default-node
Checking for docker... OK
Checking for git... OK
Checking for python... OK
Checking for pip... 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
================================
Make sure to issue a ./webodm.sh down if you decide to change the environment.
docker-compose -f docker-compose.yml -f docker-compose.plugins.yml start || docker-compose -f docker-compose.yml -f docker-compose.plugins.yml up
Starting db ... done
Starting broker ... done
Starting worker ... done
Starting webapp ... done
Creating broker ... done
Creating network "webodm_default" with the default driver
Creating db ...
Creating broker ...
Creating worker ...
ERROR: for worker UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: for worker UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
[root@survey WebODM]#
Hi @ChipwizBen,
It looks like there is some information missing from your issue that will be needed in order to diagnose and fix the problem at hand. Please take a look at the Issue Template, which will tell you exactly what your issue has to contain in order to be processable.
Also, double check that this is the right place. If you are just asking for information, reporting feedback or proposing a few feature, the right place to ask is the Community Forum, not here.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next week (until 2019-03-17 02:45) I'll close this issue so it doesn't clutter the bug tracker.
Cheers! ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
Every time, but only on one node. Sadly it's the node I use as the job dispatcher to the other nodes so when it's offline and I'm fighting with the start script, everything breaks. I thought the VM was under-resourced originally (8 cores, 4GB RAM), so I've pumped it up to 24 cores and 92GB RAM (the max for the server, less 4GB for Ceph), but it still has the same issue. The issue was occurring before it was on Ceph so I don't believe that's the issue.
I opened a forum post about how to migrate data from Docker to Native Install a couple of days ago, solely to get away from this issue.
Can't reproduce and we haven't received other reports; it might be that this was specific to the system that the software was being loaded on. Closing.