openHABian: Problem after upgrade

Hi,
today I made a major upgrade of the openHABian using openhabian-config.
Everything looked fine, but some things didn’t work.
So I checked the karaf console - and found the following error:

20:29:10.263 [ERROR] [org.eclipse.smarthome.io.rest.sse   ] - FrameworkEvent ERROR - org.eclipse.smarthome.io.rest.sse
org.osgi.framework.BundleException: Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.eclipse.smarthome.io.rest.sse.
        at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:792)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:941)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:318)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.Module.doStart(Module.java:571)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.Module.start(Module.java:439)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:454)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:717)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:491)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:437)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:955)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1336)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
Caused by: java.lang.LinkageError: ClassCastException: attempting to castbundleresource://23.fwk10389560/javax/ws/rs/ext/RuntimeDelegate.class to bundleresource://23.fwk10389560/javax/ws/rs/ext/RuntimeDelegate.class
        at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:146)
        at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:120)
        at javax.ws.rs.core.MediaType.valueOf(MediaType.java:179)
        at org.glassfish.jersey.media.sse.SseFeature.<clinit>(SseFeature.java:62)
        at org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start(SseActivator.java:44)
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_121]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        ... 14 more

Anyone got an idea what this is caused by and how I could get rid of it?

Thanks,
Boby

I also found this message in my logfiles:

21:18:00.219 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.
21:18:00.240 [ERROR] [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.

What exactly did you upgrade? openHABian or openHAB? If the second, between which revisions? Please be aware that uprgrading from a 2.0 snapshot build to 2.0 final release is not officially supported and can create problems.

Honestly speaking, I don’t know what exact version I was running before.
I used openHABian and I guess the last update from my side was done before the stable release, beginning of December. Since apt-get update/upgrade did not work anymore, I was looking up this forum - and found that I have to do sudo openhabian-config and that’s what I did.

Inside the config tool, I made the steps shown in some tutorial here:

  • update
  • basic setup
  • openHAB 2

However: What’s the best way to get a fully new openHABian installation?
Remark: I’m running my RPI on a USB-SSD, so “remove your card” woudln’t work - if possible, a scipt or a tutorial containing linux commands would be great - thank you!

Bye,
Boby

Hi Thom,
I made once more an update, basic setup & an upgrade - and now it seems
the errors are gone :slight_smile:

1 Like

The easiest would be, if you just installed it anew. Be aware that I’ve released a new version just a few days ago. I don’t know about your USB-SSD, my suggestion would be to just use an SD card :stuck_out_tongue_winking_eye:

Hi Thom,
thank you - seems to be solved now.
Just one remark: Using a SD card is NO long-termin solution: Because of
the persitence services, certain storage cells will be destroyed after a
while and leave the SD card unusable - even exensive brands.
You’ll find enough of such cases in this forum - therefore I can
recommend everyone who runs openHAB on a Raspberry to get a USB-SSD and
to move there with the OH2 installation. The SD card remains as boot
drive containing the OS which is okay (because no permanent read/write
options are ongoing on OS level).

Best regards,
Robert

Hey everyone, :wave:

SD card wear is a scare story and overrated in my opinion. Every SD card utilizes a technique called wear leveling, distributing writes to the SD card evenly over the available free memory.

I did a few measurements a while back. Sampled the writes to the SD card on my production openHAB RPi for one week, projected the results up to a year and threw the result at the promised (SanDisk) write cycles of 10’000-100’000. Even when taking the lower end of this promise plus a small 16GB SD card as an example, the SD card will supposedly survive 318 years :boom:

The following article suggests, that it is more important to have a reliable and uninterrupted power supply: http://hackaday.com/2016/08/03/single-board-revolution-preventing-flash-memory-corruption
For solutions you can for example have a look at: http://pimodules.com

I’m not saying SD cards don’t fail. Just as any other hardware, an SD card can suffer from a production problem or random failures, or simply have a bad day. For SD cards this is especially critical because the error comes in silence and the card can become unusable from on second to the other. So despite what I said above, the fear of SD card failure is real, just out of a different reason.

(I started working with RPis in May 2012 and since lost two 4GB SD cards to an write lock error of Transcend cards of that time. However there were reports by many others with less luck.)

You should concentrate on the real issue. Instead of making your home automation system less flexible (adding peripherals to an SBC) and less useful by crippling your base (making root ro or log a tmpfs), you should invest a few minutes of your time to apply some backup strategy™, solving the above and many other concerns in the right way.

Jm2c :wink:


For everyone who wants to reproduce the mentioned experiment: Here is the command to execute on your system that will generate hourly read/write statistics. Run it the command in a screen shell for a few days, then analyze the data collected.

iostat -dk 3600 >> iostat_hrly.log

Afterwards use the following table to generate your own statistics:

SD card wear calculation (Google Sheets)

1 Like

I just saw this post because Markus S. linked to it from another thread. I think it deserves to be a top-level thread of its own, probably in the Hardware section.

It would be nice to have an easy to find topic that can be linked to for the constant SD card failing posts.

And while I completely agree that a good backup and restore strategy is the solution to the SD card problem, I do think it is important for users to realize that some choices they make will have a significant impact on how long their SD card can last. For example, running InfluxDB with a * : everyUpdate strategy over a thousand Items on a 4Gig SD card is not going to last very long.

A lot of users also have an unrealistic expectation concerning how the SD corruption problem can be solved and this post provides a concrete experiment they can run to give them hard facts and hopefully come to the conclusion that its just not worth bending over backwards to prevent SD card corruption.

I myself have only ever had one SD card fail and it was running an IP camera that I failed to put the cache folder for the capture software into a tmpfs.

Besides all the nice calculations and the theoretical discussions:
My SD card quit its job after approx. 1 1/2 year of usage! I was lucky that I moved the root to my 32GB USB SSD a while ago, so I just had to reinstall the system but not OH2.

I think the main point of this posting and many others is that you shouldn’t have had to rely on being lucky. Even SSD drives fail. You should have had a backup and restore strategy in place so the failure, no matter the medium, is not a problem. And once you have that, it doesn’t really matter that the SD or SDD or HDD or whatever fails.

Put another way, spend your time and efforts on a good automated backup and restore approach rather than on making the RPi be read only or other convolutions to limit the amount of writes to the SD card.

Did you use the spreadsheet and did it tell you that the SD card should have lasted significantly longer?

Also, wear is not the only reason that an SD card will fail, especially if the RPi loses power while it is actively writing.