I need your help
My Openhab installation is starting up again and again since today… every 5-10 minutes. I use Docker for Openhab. There is enough memory and hard disk.
In Docker I get the error message Container openhab3-openhab-1 exited with status code 137 in the log of Openhab I don’t actually see any error messages.
I don’t think this is a docker problem, I think openhab have any isue…
Where can I start? What could be the error?
Thank you very much.
I have a similar problem but it started with earlier versions already. I didn’t have the time to look into this more closely. I also don’t have as many restarts as you but only a couple of times a day.
I have created a rule that notifies me when OH was started so I see how often this happens on my phone. My system hosts other applications as well but is equipped with 32GB of memory of which there are currently about 23GB in use. However I noticed that restarts often happen during times with higher system load. I still think it is still strange that this leads to restarts, other applications don’t behave like that.
I am currently having a similar issue on my docker based instance, not sure If it is related.
I just updated from openHab 3.3.x to 3.4.4. The system came up with some missing Bindings including the shelly binding. As soon as I install the shelly binding, I get the following messages in the console (log:tail):
14:47:20.436 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
14:47:22.164 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
14:47:22.871 [INFO ] [.basic.internal.servlet.WebAppServlet] - Stopped Basic UI
14:47:24.679 [INFO ] [hab.ui.habpanel.internal.HABPanelTile] - Stopped HABPanel
14:47:25.391 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
14:47:25.479 [WARN ] [b.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
After that messages, the system goes down and is restarted by docker. Memory and disk are sufficient.
By checking through some log files I discovered that my docker daemon had some trouble to resolve some(?) DNS names. I have no idea why as the config was pointing to my router which should work. Now I changed the config to point directly to my two DNS servers and the DNS issues seem to be gone. I also haven’t had any OH restarts since then but I cannot conclude that this was a result of the DNS reconfiguration as I sometimes don’t have any restarts for days.
As it may take a long time to see if my problems were really solved by this I just thought I’d mention it here so that you may check if you see similar issues in your installation.
I have now taken a new SD card and reinstalled everything and restarted Docker and the backup from yesterday.
It has been running for 12 hours now without any problems. So I guess the host had a problem, although I didn’t do anything and the installation is identical.
The SD card was only 2 months old, so I don’t think it was broken.
It’s a pity we couldn’t solve the problem any other way, it’s annoying to have to reinstall everything… I would rather have understood what happened.
I think my problems are also gone. In the past few months every now and then I had weird problems with rules that were not executed though the trigger events took place. I guess that the system was busy restarting or doing whatever during that time… So far I didn’t have any unexpected restart after the configuration change and all my rules executed as expected.
remember Java Virtual Machine memory != Physical system memory. It is entirely plausible top run out of memory in the JVM that is running OpenHAB well before getting close to the physical system memory runs out. Check you start command’s --XMax setting and consider increasing it (just not beyond 80% of the system’s physical memory).