Thanks Martin,
That was easy 
[~] # java -version
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
[~] #Yes please, because crashes like this are most of the time caused by problems in the JVM, maybe something in the new Karaf or some native libary triggers this, what kind of bindings do you have installed?
The newest available version is 152 so you could try whether that helps
I use the following bindings:
http, network, samsungtv, sonos and zwave.
Core dump is activated, I wait for the next crash.
i am having the same problem with the craches for 2/3 weeks now. UI keeps working but the items stop updating. The only way of getting the items to work again is restarting openhab.
i am op java version:
openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
the error is:
2018-01-04 21:28:52.237 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Blacklisting ServiceReference [{org.osgi.service.event.EventHandler, org.eclipse.smarthome.core.events.EventPublisher}={event.topics=smarthome, component.name=org.eclipse.smarthome.core.internal.events.OSGiEventManager, component.id=75, service.id=169, service.bundleid=110, service.scope=bundle} | Bundle(org.eclipse.smarthome.core_0.10.0.201712141004 [110])] due to timeout!
2018-01-04 21:28:52.535 [WARN ] [org.apache.karaf.services.eventadmin] - EventAdmin: Blacklisting ServiceReference [{org.osgi.service.event.EventHandler, org.eclipse.smarthome.core.events.EventPublisher}={event.topics=smarthome, component.name=org.eclipse.smarthome.core.internal.events.OSGiEventManager, component.id=75, service.id=169, service.bundleid=110, service.scope=bundle} | Bundle(org.eclipse.smarthome.core_0.10.0.201712141004 [110])] due to timeout!
Time it keeps working is around 12hrs
bindings i use http,network,mqtt,ntp,astro.
Hello, the link to the core dump to download:
Is anybody still experience similar crashes. I think my openhab installation in Docker does behave similarly and maybe I’m able to help with debugging the issue. Currently my openhab container starts using more and more memory over time and I cannot see any reason why it should:
My Install is still unstable.
I am not tracking memory usage but swap usage was high.
the CPU spikes are reboots of openhab
quick update,
I have decreased the workload on the Raspberry pi. its not the load on it.
I am going to try turning mqtt off. that seems to be the thing that crashes the system.
edit: i have turned down the rate that the sensor update lets see if that makes a diverence. my motion sensor wat trigger happy every 5 sec.
Mine’s crashing a lot too with a lot of memory usage being a cause or symptom and no warnings or errors in the (default) log.
## Release = Raspbian GNU/Linux 8 (jessie)
## Kernel = Linux 4.9.35-v7+
## Platform = Raspberry Pi 3 Model B Rev 1.2
## Uptime = 64 day(s). 21:33:24
## CPU Usage = 25.25 % avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 1.03, 5m: 0.95, 15m: 0.97
## Memory = Free: 0.07GB (7%), Used: 0.87GB (93%), Total: 0.94GB
## Swap = Free: 0.09GB (93%), Used: 0.00GB (7%), Total: 0.09GB
## Root = Free: 10.00GB (74%), Used: 3.40GB (26%), Total: 14.14GB
What can I do to help?
What are the bindings your using?
And is openhab the only thing on the server
This seems very strange issue - since top of the stack contains some Karaf related entries which are not there unless some “runtime update” is made.
r0 = 0xac25cc88
0xac25cc88 is an oop
org.apache.karaf.features.internal.resolver.CapabilityImpl
- klass: 'org/apache/karaf/features/internal/resolver/CapabilityImpl'
r1 = 0xa493aab8
Are you sure these are not caused by feature auto update or something like that? In general Karaf does not pull new snapshots alone unless there is explicit update request. From what I remember OpenHab was triggering this periodically.
Cheers,
Lukasz
Bindings:
mqtt1,kodi,chromecast,homematic,astro,rfxcom,weatherunderground,systeminfo,hue,expire1,unifi
OpenHAB is the only thing running apart from Mosquito.
did you notice anything before the crashes.
like spikes in ram or cpu?
I didn’t but I wasn’t looking.
It did it again. The was an increase in CPU load (memory load was constant at 50% and then the thing just stopped (just after 20.51) until I restarted it at 22.40).
See graph (green is memory used % and blue is CPU load).
.
Logging just stops at 20:51.
Perhaps this is just a hardware fault that has developed with my RPI?
I removed the Unifi binding and did a clean install and then a restore from my back -up and it seems okay now but:
Using the openHabian config tool to copy my files on to a USB stick didn’t work this time and I’ve no idea why - nothing worked so I had to repeat the fresh install.
Then finally MQTT didn’t work and I wasn’t able to uninstall and resinstall MQTT action as ithers have recommended as it wouldn’t uninstall so I re-installed Mosquitto again and rebooted and it worked.
It seems to be okay again but I’m really not sure I want to install the Unifi binding again in case it was that which causes the problems (unless it was a corrupt USB stick after too many writes).
The big problem I have it this seems to happen more regularly than I would like and getting it all working again should be easy but is never the same each time with different problems that need surmounting whose solutions involve spending hours going through forum threads to find answers that may, or may not work.
What’s the best current thread to enquire about the most reliable hardware solution to replace my Pi3 as it’s just not good enough for a home automation system?
I am running my system on a Rpi2b now i have made a clean install now and it has been running good for now i still need to see if it does in the couple of days. I have remade all my sitemaps and rules to be as efficient as possible. switched to inlfuxdb instead of MySQL.
all the errors that i had are gone the response time is way better. i will keep updating. i am planning on doing some tests with vm’s and running the same cofig in them but with diverend specs and simulated hardware.
I’ve ordered a SSD today which hopefully will remove that feeling that when something goes wrong that one wonders whether is a SD card or USB drive failing.
I suppose getting a spare PI and installing new bindings or upgrades on that first may also be the way to go.