Need to restart OH twice after upgrading daily snapshot release

Setup, Configuration and Use Runtime
,
1

I’m running OH2.5 snapshot releases on RPi3B+ (openhabian) for some while now.

What I noticed since a couple weeks (can’t remember when it started), is that right after upgrading, not all Items are read after starting. I always must perform a second restart for all my items to appear.

This is easily visible when trying to view my sitemap in e.g. the OH app. I then get uninitialised items displayed and the openhab.log file gets filled with lines like:

2019-07-11 12:40:00.942 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.Text
2019-07-11 12:40:00.950 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item ‘DBG_DebugMode’ for widget org.eclipse.smarthome.model.sitemap.Text

Here’s my upgrade procedure:

# 1. Display OH logging (background process):
openhab-cli showlogs &
# 2. Stop OH before upgrading
sudo systemctl stop openhab2
# 3. Perform updates and remove unneeded packages (happens occasionally)
sudo apt update
apt list --upgradable -a
sudo apt upgrade -y
sudo apt autoremove
# 4. Clean the OP cache folder and reset OH file ownerships:
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo systemctl start openhab2
# 5. And after a while...
sudo systemctl restart openhab2

I can’t find an explanation why OH doesn’t load all items files after steps 1→4.

2

I had logged an issue about this a while back. I closed it because I was unable to reproduce it in recent snapshots. I believe I opened it in openhab-core.

3

I still need to restart when changing openhab versions, e.g. 3.1M2 to 3.1 snapshot, or from snapshot to snapshot, or when downgrading from snapshot to M2.

Using docker:

docker-compose pull
docker-compose up -d # the first start up
# wait a few minutes
docker-compose restart # this shouldn't be needed
4

Yes. Upgrading destroys the system cache (rightly). Some configurations don’t manage a clean load without a functional cache. By the second load, the cache has been repopulated.

5

Sounds like a bug. OH should delay loading configurations until the cache is repopulated.

1 Like
6

indeed

1 Like
7

Issue filed for this.

8

This is fairly long-running business,it’s not as easy as you might think.

1 Like
9

I just looked at the first Issue. That was before OSGi had start level ordering.

https://docs.osgi.org/specification/osgi.core/7.0.0/framework.startlevel.html

Issue 2 looked to be about OS start levels rather that OSGi ones.

EDIT: What OSGi Level does OH 3 support? I think v8 is current and start levels have been there since v7.