OpenHAB 3.1.0.M3 Fully Frozen - Docker

Setup, Configuration and Use Runtime
,
1

Hi,

I am stuck with an annoying issue for a while now. For some reason there is a small chance that my openhab will fully freeze and not accept any new state for my Items. I can use the openhab app and habpanel they all still open. But if I want to change a state of an item nothing happens.

There is also zero event logging after openhab freezes it states (Idk what to call it different). My openhab logging is also weird, after the freeze happens I only see the following error when I want to use the habpanel or app.

[ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream.

The scary thing is that it will happen randomly and the only fix seems to fully reboot openhab.
Even my items that are filled with data through rules or bindings (for example my usage/injection) gets stuck on there state (also suddenly no logging):
image

System Info:

  • Hardware: Raspberry Pi 4B - 4 Gb - 2.4 GHz
  • Runtime: Docker Engine - Community Version 19.03.13
  • Openhab: 2.5.12 (Also happened on 2.5.10)

Edit: Also the reason that I haven’t updated to OH3 is due to an unsupported binding. I am planning to migrate in the future.

Edit2: Checked my system metrics, and there is a significant change when this happened

image
image1837×761 126 KB

Scary how suddenly my cpu is at full and my disk space is filling quickly.

2

Have a look at the thread this post An I/O error has occurred while writing a response message entity to the container output stream - #39 by matt1 belongs to.
That post defines a filter to filter out the error messages as the issue was not resolved in that thread.
Most probably you get lots of the same error message being logged at the same time.
This is why the CPU is going up and disk is filled with the same error message again and again.

3

If it is relevant, first check I would do is to verify the SD card is not starting to be corrupted.
If that is the case then I would quickly move all the data to an SSD before it dies.

1 Like
4

Sorry for the late response.

The error is not spamming, it only appears when I open the app or habpanel back then.
Also you can see in the metrics that my SSD is suddenly filling up with data, and when I restarted it suddenly disappears. So it has to be a memory issue or some files that are increasing rapidly in size which has no volume map with docker.

I think the error has no relationship with the sudden spike in my cpu of openhab and freezing everything.

5

Thanks for the tip, made a backup. Next time this happens I will take the time and analyse further while its going on. Restarting the openhab container will fix it, but you will have no idea where the spike came from or what is going wrong.

Also planning to move to a barebone later instead of an rpi.

6

I hope I this topic will get more attention now.

A month ago I had this issue with OH2.5, only solution seems to upgrade to OH3.
Now today the exact issue happened again !

All my item states are locked into there state, following things seems to happen:

  • Items do not change on input from pages, habpanel or sitemaps

  • Items stop persisting on change, example my smartmeter usage that is read every ± 10s
    image

  • No event logging after events happens

  • CPU is at full load for the openhab container (back normal after openhab reboot)
    image

  • Disk is increasing in size fast ! (Increased size is cleared after openhab reboot)
    image

Things I tried to prevent this:

  • Replace SD card
  • Upgrade to OH3 latest version (3.1.0.M3)
  • Give openhab container more memory and cpu

But none of this worked. It seems an openhab issue because all my other containers worked perfectly. For example my prometheus perfectly logged my rpi metrics while openhab was totally frozen. So it’s not an hardware issue.

The problem is that I have zero logging coming from openhab because it will totally freeze, the only logging I see are some normal transform map warnings:

2021-06-05 11:24:53.662 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '0.16666700' with the file 'blinds.map' : Target value not found in map for '0.16666700'

Anyone with some tips ? I hope next time I have the time to analyse what is causing the disk size.

7

Latest or M3?
image

From Docker

After upgrading it takes a while for OH to build a new cache.

8

Sorry my fault, its “3.1.0.M3” not “latest” in docker tag terms
image

it was the “latest” version when I did the upgrade ± 2-3 weeks ago.

9

M3 has been replace my M4 & M5. In fact there were major OSGi upgrades between M3 & M4 in addition to bugfixes.

Milestone versions are only designed for testing to aid in development of the upcoming stable version. If you can reproduce the issue when running M5 perhaps someone can help.

10

Thx for the tip, I will do the upgrade to M5.

However it’s weird that I have the exact same issue with OH2.5.

11

What addons are you using? One common culprit that needs to be uninstalled is restdocs. Its functionality was moved in 2.5 and is included in the OH3 core functionality.

Post the addons.cfg file from the configuration area ($OH_CONF/services/addons.cfg) and the addons.config file down in the userdata tree.

12

Sorry for the late response, these are my addons:

package = minimal
remote = true
legacy = true
binding = chromecast, icloud, openweathermap, dsmr, http, mqtt, telegram
ui = basic, habpanel
persistence = influxdb
transformation = map, jsonpath, xpath

userdata addons

:org.apache.felix.configadmin.revision:=L"9"
action="pushover,\ telegram,\ mail"
binding="chromecast,\ icloud,\ openweathermap,\ dsmr,\ http,\ mqtt,\ telegram"
legacy="true"
package="minimal"
persistence="influxdb"
remote="true"
service.pid="org.openhab.addons"
transformation="map,\ jsonpath,\ xpath"
ui="basic,\ habpanel"

I also use 1 custom binding and that is “openHAB-Simatic” to communicatie with my PLC.

13

There was an MQTT breaking change listed in the 2.5.0 Release Notes.

MQTT Binding

Homie channel names may have changed if special characters are used for MQTT topic names

I see nothing else in the Release Notes but the latest now is Milestone 5. I doubt you will get .much support in running older Milestones that have served their purpose.

14

I have installed the MQTT binding but im not using it yet. So no things nor settings are used.

Im running M5 now, so lets hope it won’t happen again.
If it happens again I will provide more detail, for example what is causing the disk size increase.

1 Like
15

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.