search

openhab / openhab-docker

Repository for building Docker containers for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
212 stars 128 forks source link

addons put in userdata/tmp rather than addons volume #287

Closed hauntingEcho closed 4 years ago

hauntingEcho commented 4 years ago

Using the openhab/openhab:2.5.3-armhf-debian image, any addon installation seems to be going to the userdata/tmp folder rather than the addons folder.

I currently have the Zigbee Binding addon installed, and can see its associated serial libraries in userdata/tmp while addons is empty:

$ docker container exec -it openhab /bin/bash
root@helios4:/openhab# ls /openhab/addons/
root@helios4:/openhab# ls /openhab/userdata/tmp/
ac86692d-activation-1.1.1.jar  bundles  fileinstall-6596360509192717131  fileinstall--7332956597533701987  instances  kar  karaf.pid  libNRJavaSerialv5_openhab_0  libNRJavaSerialv6_HF_openhab_0  libNRJavaSerialv6_openhab_0  libNRJavaSerialv7_HF_openhab_0  libNRJavaSerialv7_openhab_0  libNRJavaSerialv8_HF_openhab_0  libNRJavaSerialv8_openhab_0  lock  mvn  port  README  tmp
root@helios4:/openhab#
wborn commented 4 years ago

There are a few misconceptions here:

  1. The /addons dir is where you place add-on .jar files that you want to be installed. These .jar files contain the code of the add-ons and not the data they operate on. See the documentation. Any add-on specific data is stored in /userdata. Usually there is none. Some TTS voice add-ons cache synthesized speech audio files in /userdata/cache
  2. The serial libraries are not part of the Zigbee binding add-on. Typically add-ons share this library using the openhab-core serial transport. So this is not add-on data.
  3. All this behavior is not specific to the openHAB Docker container. You'll also run into this when using the Debian package or .tar.gz distro. We merely package openHAB into a Docker container in this repo. ;-)

The reason these libraries are extracted to /userdata/tmp is because they are embedded into the nrjavaserial library we use for serial communications. It uses this mechanism so it can dynamically extract/load the correct native library code depending on the architecture.

As a developer that is a really convenient way for shipping native code so you don't have to add the library to the java library path (without it ever being used at all) so it can be loaded on demand.

The only catch so far seems to be it doesn't work well with a filesystem having the noexec flag as you reported in https://github.com/openhab/openhab-docker/issues/286.

If you want to keep using the noexec flag you should reconfigure the java.io.tmpdir for your specific use case.

You could also create an issue/PR to make this location more configurable in the nrjavaserial library. Though there can also be other code in openHAB that may have very good reasons to create executable files in the java.io.tmpdir that won't be addressed by this.