Localhost:3000 seems to be offline

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.

odm@WebODM:/home/xxx$ cd /code
odm@WebODM:/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
root@WebODM:/code# sudo chown odm:odm -R /code
root@WebODM:/code# cd /code
root@WebODM:/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.

email sent

1 Like

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. https://github.com/OpenDroneMap/OpenDroneMap/issues/876 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 https://docs.docker.com/machine/drivers/vsphere/

There’s also a community supported driver for Workstation Pro. See https://github.com/pecigonzalo/docker-machine-vmwareworkstation

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