java.lang.RuntimeException: DyNet could not be loaded!

[GourReetika]

I am trying to run reach service in docker container, I could get the server up but it is not able to find the "libdynet_swig.so." when hitting "reach.process_text" endpoint. Any leads to this will be helpful.

Please find the screenshot attached.

[MihaiSurdeanu]

@kwalcock : can you please look into this? Thank you!

[kwalcock]

At runtime, the software wants to extract libdynet_swig.so from the jar and write it into the /tmp directory unless it has found an existing copy in /reach or /root. It appears to have been successful at that. Then it tries to load the file. That doesn't seem to have worked. The typical cause would be an unsatisfied linking error. libdynet_swig.so is not completely statically linked and depends on a few shared objects that might not be present in this docker environment. It will also probably go wrong in a similar way if you are using an unexpected processor like ARM while running Linux.

If you can get a shell running in the container, you may be able to find the temporary file (e.g., /tmp/libdynet_swig-353...) and check whether it has everything it needs with ldd. Otherwise you can also extract the file libdynet_swig.so yourself from the reach or processors jar, whatever you are running, and check whether ldd spots any missing dependencies.

HTH

[GourReetika]

I looked inside the container:
"libdynet_swig.so" file is not present in /reach, /root or /tmp either.

There are two jar files with the name processor available processors-main_2.12-8.5.3.jar and processors-models-0.2.4.jar. "libdynet_swig.so" is not present in either of them

The "uname -m" command inside the container returns "aarch64" so it is probably not ARM.

[kwalcock]

The .so file wouldn't be in /reach or /root unless someone put it there intentionally. The copy that is written to the /tmp directory at runtime is usually erased when the program completes execution, but it might stay around if the program crashes. The file can be found at https://github.com/clulab/fatdynet/tree/master/src/main/resources and it would be somewhere in the docker image, probably in a hidden .m2 directory and then buried in a jar file. If you can get the github copy into the container, then that would be good enough for ldd to evaluate.

The aarch64 means it's the Apple chip, which is based on ARM. If you are running in docker, that's basically Linux. Linux on ARM is not supported in the version of processors, 8.5.3, that reach is configured to use. ldd likely says something about the file not being compiled for the hardware found. You would probably need to make sure that docker used some base image for Intel or AMD hardware and then hopefully Rosetta takes care of the rest. The FROM command in the Dockerfile might need to be changed as below.

FROM --platform=linux/amd64 ubuntu:focal

You could also just run the reach directly on MacOS, which should be supported for both Intel and Apple architectures for all its dependencies.