Brand new install on a clean, untouched Ubuntu 16.04 server. First use.
Can login, and interface works perfectly, but I have no processing node (even localhost):
“localhost:3000 seems to be offline”
“There are no usable processing nodes. Make sure that at least one processing node is reachable and that you have granted the current user sufficient permissions to view the processing node (by going to Administration – Processing Nodes – Select Node – Object Permissions – Add User/Group and check CAN VIEW PROCESSING NODE). If you are bringing a node back online, it will take about 30 seconds for WebODM to recognize it.”
I also tried adding the processing node back by direct IP address…no change.
Hey @mcevoys, did the nodeodm service start? What’s the output of:
sudo systemctl status nodeodm
nodeodm.service - Start node-ODM Service Container
Loaded: loaded (/www/services/nodeodm.service; enabled; vendor preset: enable
Active: inactive (dead) (Result: exit-code) since Sun 2018-08-19 09:02:01 EDT
Process: 1496 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCE
Process: 1483 ExecStart=/usr/bin/node index.js (code=exited, status=1/FAILURE)
Main PID: 1483 (code=exited, status=1/FAILURE)
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Unit entered failed state.
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Failed with result 'exit-cod
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Service hold-off time over,
Aug 19 09:02:01 WebODM systemd[1]: Stopped Start node-ODM Service Container.
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Start request repeated too q
Aug 19 09:02:01 WebODM systemd[1]: Failed to start Start node-ODM Service Contai
lines 1-13/13 (END)…skipping…
● nodeodm.service - Start node-ODM Service Container
Loaded: loaded (/www/services/nodeodm.service; enabled; vendor preset: enable
Active: inactive (dead) (Result: exit-code) since Sun 2018-08-19 09:02:01 EDT
Process: 1496 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCE
Process: 1483 ExecStart=/usr/bin/node index.js (code=exited, status=1/FAILURE)
Main PID: 1483 (code=exited, status=1/FAILURE)
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Unit entered failed state.
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Failed with result 'exit-cod
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Service hold-off time over,
Aug 19 09:02:01 WebODM systemd[1]: Stopped Start node-ODM Service Container.
Aug 19 09:02:01 WebODM systemd[1]: nodeodm.service: Start request repeated too q
Aug 19 09:02:01 WebODM systemd[1]: Failed to start Start node-ODM Service Contai
Looks like the service failed to load.
What happens if you launch:
sudo su odm
cd /www
node index.js
Any errors?
error: Error during startup: Could not load list of options from OpenDroneMap. Is OpenDroneMap installed in /code? Make sure that OpenDroneMap is installed and that --odm_path is set properly: Unexpected token T in JSON at position 0
Ok, so something doesn’t seem to be right with the ODM component.
If you run:
sudo su odm
cd /code
./run.sh --help
Do you get an error?
Also, could you share some information about the cloud setup (which provider, which VM settings) you used? It could help us reproduce the problem from the script.
[email protected]:/home/xxx$ cd /code
[email protected]:/code$ ./run.sh
Traceback (most recent call last):
File “/code/run.py”, line 4, in
from opendm import config
File “/code/opendm/config.py”, line 5, in
from appsettings import SettingsParser
ImportError: No module named appsettings
This is a captive (not cloud) VMWare ESXi 6.7 server. 8 x vcpu and 64GB of memory dedicated
Thanks for the information.
Try:
sudo su
cd /code
bash configure.sh reinstall
This will take a while, when it’s done do:
sudo chown odm:odm -R /code
cd /code
./run.sh --help
This should show the help menu of OpenDroneMap. If it does, to start node-ODM do:
sudo systemctl restart nodeodm
Then the processing node should show up in WebODM.
Is the server running Ubuntu Desktop or Server 16.04 LTS? Just trying to understand if the environment is the cause the installer didn’t work right out of the box.
2 Likes
Configuration Finished
[email protected]:/code# sudo chown odm:odm -R /code
[email protected]:/code# cd /code
[email protected]:/code# ./run.sh --help
Traceback (most recent call last):
File “/code/run.py”, line 11, in
from scripts.odm_app import ODMApp
File “/code/scripts/odm_app.py”, line 5, in
from opendm import types
File “/code/opendm/types.py”, line 5, in
from opensfm.exif import sensor_string
ImportError: No module named opensfm.exif
Running 16.04 Server LTS
Restarted the service anyway, and it seems to be online, but a simple project (70 images) fails:
File “/code/run.py”, line 11, in <module> from scripts.odm_app import ODMApp File “/code/scripts/odm_app.py”, line 5, in <module> from opendm import types File “/code/opendm/types.py”, line 5, in <module> from opensfm.exif import sensor_string ImportError: No module named opensfm.exif
Multiple different jobs failed with same error code (1)
Beginning to wonder if this is more science project than something I should have paid for.
Clearly something is not building. If you received an error when running ./run.sh, it’s not going to work.
Any chance you could give me SSH access to the machine to investigate? You can forward the information to my e-mail.
The problem seem linked to the virtualization environment that you are using. The build process fails during the compilation of one of our dependencies:
[ 55%] Building CXX object libs/tex/CMakeFiles/tex.dir/view_selection.cpp.o
In file included from /code/SuperBuild/src/mvstexturing/elibs/mapmap/mapmap/header/vector_math.h:354:0,
from /code/SuperBuild/src/mvstexturing/elibs/mapmap/mapmap/header/costs.h:23,
from /code/SuperBuild/src/mvstexturing/elibs/mapmap/mapmap/full.h:15,
from /code/SuperBuild/src/mvstexturing/libs/tex/view_selection.cpp:14:
/code/SuperBuild/src/mvstexturing/elibs/mapmap/mapmap/source/vector_math.impl.h: In function ‘void mapmap::v_masked_store(mapmap::_v_t<COSTTYPE, SIMDWIDTH>&, mapmap::_iv_t<COSTTYPE, SIMDWIDTH>&, mapmap::_s_t<COSTTYPE, SIMDWIDTH>*) [with COSTTYPE = float; unsigned int SIMDWIDTH = 4u; mapmap::_v_t<COSTTYPE, SIMDWIDTH> = __vector(4) float; mapmap::_iv_t<COSTTYPE, SIMDWIDTH> = __vector(2) long long int; mapmap::_s_t<COSTTYPE, SIMDWIDTH> = float]’:
/code/SuperBuild/src/mvstexturing/elibs/mapmap/mapmap/source/vector_math.impl.h:1057:33: error: ‘_mm_extract_epi64’ was not declared in this scope
a1.i = _mm_extract_epi64(aa, 0);
This is a bug. I’ve opened an issue to track it. Cannot compile ODM natively on a certain CPU architecture · Issue #876 · OpenDroneMap/ODM · GitHub ODM cannot run natively on your environment, so the installer won’t work for you. I’ve sent you a full refund.
Your other options are to 1) Use docker 2) Use a different environment.
Sorry that the program didn’t work. We’re always trying to improve it and support as many platforms as possible.
I guess I’m confused…this is standard, current ESXi, the most prevalent virtualization environment around.
It is common — it’s what I use. But you were the first to find the bug (I always run through docker on this environment).
But would ESXi → Ubuntu → Docker solve the issue? Or would the underlying issue still remain?
Tried to run under Ubuntu 10.04LTS (clean install) on VMWare Workstation Pro
Won’t even install.
What non-docker virtualization works?
Perhaps it’s not the virtualization per se. Maybe it’s triggered by the underlying CPU architecture. _mm_extract_epi64 is a SSE4 optimization instruction found on recent CPUs. I’m not really sure why mapmap would fail to build, we don’t maintain the library and more time is needed to find the cause and propose a fix.
There’s a driver to use docker on VMware vSphere. Check Docker Desktop | Docker Documentation
There’s also a community supported driver for Workstation Pro. See GitHub - pecigonzalo/docker-machine-vmwareworkstation: VMWare Workstation driver for Docker Machine https://github.com/docker/machine
The docker driver for vSphere requires a spendy license…defeats the purpose of ODM/WebODM at that point.
Did some digging. My Xeon X5690 processors support SSE4.2, so lack of SSE isn’t the issue on this bug