[Solved] OH4.0.1-1 stuck on startlevel 70

Setup, Configuration and Use Migration
1

Any hint on how to investigate? Been like this since 4.0.0~M2-1
System appears to not suffer much not reaching startlevel 100

{
  "systemInfo": {
    "configFolder": "/etc/openhab",
    "userdataFolder": "/var/lib/openhab",
    "logFolder": "/var/log/openhab",
    "javaVersion": "17.0.8",
    "javaVendor": "Private Build",
    "osName": "Linux",
    "osVersion": "5.15.0-78-generic",
    "osArchitecture": "amd64",
    "availableProcessors": 2,
    "freeMemory": 309006632,
    "totalMemory": 643825664,
    "startLevel": 70
  }
}
2

Use debug level logging on org.openhab (and org.apache, eventually) as a starting point.

3

There was a problem in early milestone releases of OH 4 like M2 where if a Thing doesn’t come ONLINE start level 100 is never reached. That was fixed in subsequent releases.

Note that snapshots and milestone releases are not really intended to be used for the long term. It’s almost impossible to support these versions because they require knowledge that isn’t well documented anywhere (e.g. which bugs existed at that time). If you do not intend to keep up with the latest milestones (4.0 M2 was six months ago now) please stick with the releases.

4

OP is on 4.01 Rich… :wink:

5

Doesn’t that mean Milestone release 2?

6

since …

7

Ah, missed that. Need more coffee.

Well, I guess the same idea applies though. Is there a Thing that isn’t reaching ONLINE during startup?

3 Likes
8

Enabled DEBUG log for org.openhab and restarted.
First run (attached log), I noticed the Twinkly binding complained a bit since my Christmas lights are not connected.
Removing Twinkly did nothing. Still stuck at startlevel 70.
I read the logs for an hour or so, but could not see anything that caught my eye.

If somebody a bit more fluent in reading openhab logs could take a look, I would be grateful.
Searching for StartLevelService showed that it only logged reaching level 0.
Attached file (remove .log extension)
org.openhab.debug.gz.log (363.0 KB)

Info: there is a host posting to the rest api during startup (GTV7PowerConsumption)
This ends up well, and have been like this for years, so that should not be a problem.

During restore from influxDB, both java & influxdb hogs CPU for 1-2minutes. (lots of historical data)

9

To answer my question doesn’t involve logs. Once it’s started up look at Settings → Things. Are there any Things there that are not ONLINE?

10

Some.
Some I have Disabled manually, but these 3 are flagged as Offline

image
image926Ă—81 4.46 KB

image
image901Ă—68 4.61 KB

image
image924Ă—70 5.25 KB

First 2 are removed, 3rd is a battery eater, so also removed.

11

And what do you know!
Disabled those 3:

{
  "systemInfo": {
    "configFolder": "/etc/openhab",
    "userdataFolder": "/var/lib/openhab",
    "logFolder": "/var/log/openhab",
    "javaVersion": "17.0.8",
    "javaVendor": "Private Build",
    "osName": "Linux",
    "osVersion": "5.15.0-78-generic",
    "osArchitecture": "amd64",
    "availableProcessors": 2,
    "freeMemory": 75124832,
    "totalMemory": 617611264,
    "startLevel": 100
  }
}

Didn’t even have to restart … :slight_smile:

12

I was going to recommend that.

This is probably worth filing an issue. Though it’s a trick problem. Runlevel 80 is supposed to mean “Things initialized”. If a Thing never becomes ONLINE does that mean things are never initialized? Should a broken Thing prevent advancing to runlevel 100?

Maybe it can be as simple as treating a Thing as initialized so long as it changes from INITIALIZING to any other state, not just ONLINE.

13

Yes, guess this has been refactored lately. Didn’t seem to have any practical implications though.
Only reason I noticed was that J-N-K asked me to check it when I had problems with restoring from influxDB in 4.0.0-M3. This issue looks OK now, just a few items timing out. The 5s timeout could be marginal on systems with a large database.

Anyway, thanks for helping out!