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?
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.
I deleted the userdata/etc/org.apache.karaf.features.xml following discussion from issue #1354here. A third restart of the docker image and things appear back to normal with 3.2.0
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):
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?
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.
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.
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.
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 ^^.
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.
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.
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):