Issues with running OpenHab 3.2 Docker image

Setup, Configuration and Use Installation
1

I’m trying to run the following (completely new) installation of openhab 3.2 on Raspberry Pi 4/raspbian, using docker compose:

version: '2.2'

services:
  openhab:
    container_name: openhab
    image: "openhab/openhab:3.2.0"
    restart: always
    network_mode: host
    volumes:
      - "/etc/localtime:/etc/localtime:ro"
      - "/etc/timezone:/etc/timezone:ro"
      - "./addons:/openhab/addons"
      - "./conf:/openhab/conf"
      - "./userdata:/openhab/userdata"
    environment:
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
      USER_ID: "999"
      GROUP_ID: "995"
      CRYPTO_POLICY: "unlimited"
    devices:
      - /dev/serial/by-id/usb-0658_0200-if00

Unfortunately after showing the final (based on docker logs)

Launching the openHAB runtime...

nothing happens, ie the OpenHab does not start and “userdata/log/openhab.log” remains empty. If I just switch the image version to 3.1 everything works perfectly.
Anyone experienced that too?

2

My docker image was openhab/openhab:latest. We had a major power outage last night and when docker restarted had a few issues with the script reloading, trying to upgrade to 3.2.0.

I manually updated to openhab/openhab/3.2.0 but had to also manually change my environmental variable to 3.2.0 to get it to load.

Openhab now starts up, but still have an issues with the influxbd persistence service. I have removed this, reinstalled and restarted. The Influxdb persistence service menu item is visible on the settings > other services menu but is empty. Will keep looking.

1 Like
3

I deleted the userdata/etc/org.apache.karaf.features.xml following discussion from issue #1354 here. A third restart of the docker image and things appear back to normal with 3.2.0

4

same here - but deleting the features.xml did not solve the problem for me (although after several restarts) - any further ideas?

6

I tried with completely empty instance (ie. all folders such as userdata empty)

7

this was my starting point (docker container from scratch) :frowning:

8

If you also see this warning:

OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes

Have a look at: Docker openhab:3.2.0-snapshot stuck at unhealthy with OpenJDK Client VM warning: No monotonic clock was available

9

great, that worked, Thanks!

1 Like
10

Indeed I had this warning (since it was a warning I ignored it and not expected that it would hang up the machine). Anyway, I installed the latest libseccomp2 in raspbian (the Docker host):

libseccomp2/buster-backports,now 2.5.1-1~bpo10+1 armhf [installed]

But I’m still getting this warning

OpenJDK Client VM warning: No monotonic clock was available - timed services may be adversely affected if the time-of-day clock changes

Am I missing something?

11

If it doesn’t work after updating the library, I would try restarting Docker or the RPi4. :slight_smile:

12

I tried to restart everything, but nothing helped. Could it be that I’m still using raspbian based on Debian 10 while OpenHab 3.2 Docker image is based on Debian 11?

13

Those old versions of libseccomp2 block time64 system calls used by newer OS-es. With the library update those system calls are whitelisted. So you can also run into this issue with other container images based on a recent OS.

If you cannot update the library for some reason, you can also disable seccomp for the container. But that of course significantly impacts security in a negative way. See Run without the default seccomp profile.

See also seccomp on Wikipedia.

14

I think the version which I have installed is the latest one, right?

libseccomp2/buster-backports,now 2.5.1-1~bpo10+1 armhf [installed]

Additionally when I check with lsof the /usr/lib/arm-linux-gnueabihf/libseccomp.so.2.5.1 lib is actually used by docker, so I have no idea what’s going on.

Thanks for the hints with disabling seccomp, I’ll play with it to see if it makes a difference.

15

Today I tried to upgrade from Docker Image 3.1.1 to 3.2.0 a couple of times, without any success. All my things are after a complete start of openhab in an uninitialized status. And if I open a thing, it is empty. In the log files nothing of interest happens.

Anyone has the same problem with that upgrade to 3.2.0?

I am using a Raspberry Pi 4 with Raspbian 10 docker installation.

16

Hi,

The same for me after upgrading from 3.1.1 to 3.2.0 on docker (Synology), Influxdb service not loaded, and many other addons (knx, etc). Just Onkyo and Modbus addons load. So no other things but items were present.
And I saw that it was slowly restoring (restore at startup option in persistence file) so I change the persistence policy. Don’t know if it helps
Deleting the userdata made finally the job, and also … wait !
Does openhab server suffer from its success ?! This release was a beautiful present for Christmas ^^.

Regards,

17

I found the solution for me: Openhab 3.2 on Docker: no monotonic clock was available

Otherwise docker image update from 3.1.0 to 3.2.0 didn’t boot on raspberry 4. Since this is a big issue for (most/all?) raspi container users, this should be in the upgrade informations for openhab imho.

1 Like
18

Same for me. After updating Openhab from 3.1.0 to 3.2.0 on a docker installation on a rpi i got the “No monotonic clock was available” error at first. I was able to resolve it, but after that a lot of items were in an uninitialized state.

All MQTT things stayed in an uninitialized state, but the MQTT bridge thing was in “Online” state. After restarting the MQTT bridge thing, all MQTT items wnnt into ERROR BRIDGE state.

Also other items stayed unitialized, for example the openweatherapi thing.

The only clue i could find was related to perrmissions for the tmp folder:

Failed to load native library:jansi-2.4.0-ffc4f60c3ac1c2db-libjansi.so. The native library file at /openhab/userdata/tmp/jansi-2.4.0-ffc4f60c3ac1c2db-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location.  osinfo: Linux/armv7

In the end i had to revert to openhab 3.1.0 using a backup of the config.

Don’t know how to get to 3.2.0 :frowning:

19

Hi everyone. I’m not sure if I can help but I run OH 3.2 as docker on a raspberry pi 4 with raspbian 10 (buster) without any issues.

If it can help, here is my compose file:

version: '3.0'

services:
  openhab:
    image: "openhab/openhab"
    restart: always
    network_mode: bridge
    ports:
      - 8080:8080
      - 8101:8101
      - 5007:5007
      - 8443:8443
    volumes:
      - "openhab-addons:/openhab/addons"
      - "openhab-conf:/openhab/conf"
      - "openhab-userdata:/openhab/userdata"
      - "openhab-cont-init:/etc/cont-init.d"
    environment:
      OPENHAB_HTTP_PORT: "8080"
      OPENHAB_HTTPS_PORT: "8443"
      EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Brussels"
      TZ: "Europe/Brussels"
      GROUP_ID: 9001
      USER_ID: 9001
    healthcheck:
      test: "curl --connect-timeout 5 --silent -f http://localhost:8080/ || exit 1"
      interval: 5m
      timeout: 5s
      retries: 3
volumes:
  openhab-addons:
    external: true
    name: openhab-addons
  openhab-conf:
    external: true
    name: openhab-conf
  openhab-userdata:
    external: true
    name: openhab-userdata
  openhab-cont-init:
    external: true
    name: openhab-cont-init

I run some other containers on the pi as well but it’s mostly for OH. I have done some special things to this pi that could explain why 3.2 is working for me but not for you. I copy the lines over from my bash history (sorry I don’t remember why I did those things):

sudo apt-get install -y libffi-dev libssl-dev

wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb
sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb
sudo reboot

It’s possible that I did a /cache and /tmp cleanup after upgrading

20

tried again today, I uninstalled a couple of bindings that were throwing errors (influxdb, denonmarantz), cleared the cache & tmp and did a reboot.

Looks like it works now, fingers crossed!

21

Thanks, that fixed my problems as well.

1 Like