OSGI Bundles not ACTIVE after install - How to detect?

Setup, Configuration and Use Installation
1
  • Platform information:
    • OS: Ubuntu Core 18
    • Java Runtime Environment: Azul OpenJDK Java 8
    • openHAB version: 2.5.4
  • Issue of the topic: Installing OpenHAB 2.5.4 as an ubuntu snap, most installs work great but occasionally not all the bundles load correctly. Sometimes this means the REST api is not available or the console is not available. It is not always the same bundles that do not go to ACTIVE. If I remove the snap and install again it usually works, indicating that there is some startup sequence or environment issue that caused the problem. Is there any way to get the installed bundles and their state besides the console? Maybe via the REST api? Ideally via Server Sent Events? I suppose there is an exposed JMX port? I need a way to indicate that the install was not completely successful, so the snap will rollback and try again.
2

Does the Ubuntu snap install all the components locally or do they point to dynamic download via Maven during startup ? In case it tries to download the stuff via Maven then this would be the problem:

3

Think of a snap as a container, but with all the code already packaged. This is the default OpenHAB 2.5.4 download plus a Zigbee binding already in the snap. That is it. What is downloaded is the entire snap and it is verified after download. My guess would be that about 2% of installs of the exact same code on the exact same hardware have problems with bundles not fully starting. I am hoping to find a way to detect the problem.

4

I’d rather recommend to drop the snap idea unless there’s an up to date version available.
It’s exotic, plus your 2.5.4 is ancient. Lots of potential for errors.
Manual installation on the other hand is not a big deal.
You should be getting at least the latest 2.x version which is 2.5.12, or if you’re starting anyway start with OH 3.1 right away.

5

Thanks. We are currently testing and snaps allow for easy management. We have performed 5000 installs of this snap and about 2-3% have issues with all the bundles being resolved and going to Active. So roughly 120 failures. I will pursue the JMX route as a potential for automating the snap re-install process when an issue is detected. We are looking at upgrading to OH3. Thanks.

6

“Manual” installation is just a couple commands, simple and automatable, too (Ansible, Puppet, whatever). Docker OH image is there, too. And there’s Debian, of course.
All are better choices than running an outdated application version sacrificed for ease of management.

7

I think we are getting off topic of finding a way to inspect or listen for bundle state.

My use case may not be typical and may be exotic but I think it is still valid. I suspect if you do 5000 manual installations you will also have 2-3% where the bundles do not all startup correctly. Was this an issue that was detected and resolved in newer versions, and therefore I should definitely upgrade because it is known bug that has been fixed? We do plan to upgrade at some point but I do not think my question is specific to version. Does OH3 has better exposure of bundle state?

Snaps is the architecture we have selected for security and maintenance. OH is only one bit of software that we are testing to add as an available snap.

Lastly, I am not sure what the difference is in puling down OH and packaging as a snap, versus having a snap startup and pull down OH.

I appreciate your help but I included the OH version and architecture to help point to an answer about bundle state, not so my question can be dismissed until I do things in a more standard way.

8

Of course it is. As I said 2.5.4 is ancient. There have been Karaf upgrades and many fixes and changes since, also on bundle and cache handling and the whole startup procedure.
Proceeding with that is a waste of time IMHO (time is yours of course :slight_smile: ).