"Demo app" stuck at startlevel 10

Development
1

I just updated my Core development environment branch to latest main (I moved from b3e583867ebbda437f54dae0e449a75373c3662b to 2b594e0944321491f3ae177617dabb94acbb3003). At first there were a lot of errors because it couldn’t resolve the new class PersistenceServiceProblem, but after rebuilding the entire Core, I finally got rid of that problem. But, something is still off, because I cannot get the system to proceed past startlevel 10.

I have different branches checked out for add-ons, distro, zwave etc., so the opportunities for complicates are many, but the only thing I changed that triggered the problem was switching Core commit.

I don’t know quite where to look, since there are no errors in the log. It seems to start pretty normally, it starts to discover a few mDNS and UPnP devices, and then nothing more happens. No errors.

I’ve tried reverting the JUPnP update, with no apparent result. I guess I will just have to try to check out commits in between to see when then problem appears, but it can easily take > 1 hour to build and resolve everything after checking out a new commit, so I fear this will be a slow process.

Any ideas of what might be causing this are appreciated.

2

I added debug logging, which makes this pop up indefinitely:

[DEBUG] (OH-startlevel-1     ) [enhab.core.service.StartLevelService] - Missing marker dsl=persist for start level 20
3

I’m unable to do anything until this has been resolved - since dsl=persist is mentioned in the log, maybe you have some idea @Mherwege?

Have any start levels been changed in the Karaf configuration and not in the demo app?

4

I don’t have any idea how the persistence modifications could have influenced this. I need to check.

1 Like
5

We already have something like this at some place in the past.
As far as I remember, the was because generally, you don’t have persistence in dev environment.
I try to find back the reference about this.

6

Yes, that’s true, you don’t run persistence, so whenever something assumes that you do, it breaks in the dev environment.

7

I’ve find back the reference, it was about service.cfg and new marker introduce in the code that don’t match. But this quite old, end of 2024.

8

I remember the situation, it took months to resolve - but it stalled it on a higher startlevel, 70 or 80 - as far as I can remember. It meant that “most things” worked, but managed Things wouldn’t initialize.

This time, it stops very early…

9

It was no so high as far as I remember, i think it was stuck at level 20 or 30.

10

With updating core in Eclipse, did you also update the distribution? Is the persistence DSL bundle open in Eclipse? Did you make sure it is recompiled, so it is not using a bundle from cache?

It kind of looks like an old compiled bundle for the persistence DSL is used, and that could be the reason it does not become active anymore.

11

No, because I have done so much tweaking of distro (because that’s basically where you configure the dev environment). But, I’ve looked for relevant commits in distro that might impact this, but haven’t found any.

I’ve tried “everything” in this department, recompiled Core completely several times, restarted Eclipse, bnd resolved everything, etc..

But, I found a way to make it start now:

When I remove dsl:persist from the above line, it starts.

The question is why, and if that is “the fix”. Why was this there in the first place, and is the removal of a default strategy what leads this to no longer be satisfied?

12

if it’s marker dsl:persist, it’s manager by FolderObserver in org.openhab.core.model.

As far as I remember, this stuff are there to be sure that openhab check for config files changes in respective directory. In this case runtime/conf/persistences.

As far as I also remember, the fact that the directory is there or not here on disc should not be a problem.

13

I’m trying to start on my side to see if I can give you a stack trace of the normal process.

14

I have runtime/conf/persistence and it contains an old mapdb.persist file from November 2024. But, it should start regardless of this folder..?

That’s one of the bundes that I can’t open in Eclipse, so that’s one of the areas I know nothing about. I don’t understand how others work with these bundles, because the Maven build is “broken” since it writes to the source folders, leading to an endless build loop (because Eclipse detects that the source has changed, and triggers a new build every time it builds).

edit: The above is wrong, it turns out that org.openhab.core.model.core is one of the few “model” bundles that aren’t broken in Eclipse.

15

So on my side, it’s activated on this method:

@Reference(cardinality = ReferenceCardinality.***AT_LEAST_ONE***, policy = ReferencePolicy.***DYNAMIC***)

    **protected** **void** addModelParser(ModelParser modelParser) {

        String extension = modelParser.getExtension();

        logger.debug("Adding parser for '{}' extension", extension);

        parsers.add(extension);

        **if** (activated) {

            processIgnoredPaths(extension);

            readyService.markReady(**new** ReadyMarker(***READYMARKER_TYPE***, extension));

            logger.debug("Marked extension '{}' as ready", extension);

        } **else** {

            logger.debug("{} is not yet activated", FolderObserver.**class**.getSimpleName());

        }

    }

Stacktrace is an OSGI activation stack trace.
Source class for it is:

‘org.openhab.core.model.persistence.runtime.internal.PersistenceRuntimeActivator’ (id=233)’

So as Mark said, perhaps you have this bundle : org.openhab.core.model.persistence / org.openhab.core.model.persistence.runtime that is not compiled correctly, or that for some reason don’t activate correctly.

16

I doubt that’s the reason, since I don’t have org.openhab.core.model.persistence open, so Eclipse won’t “mess with it” but resolve it like any other Maven dependency. It should either use the result of my latest full Core build, or download it from the snapshot repo.

But, I’ll see if I can debug the class during startup.

17

I don’t have it also on my side into the project.
But I don’t see others good possible reason.
If you don’t hit this point, is that something prevent org.openhab.core.model.persistence.runtime to load/activate.
I will try to upgrade on my side to see if I hit the same trouble.

18

I’m currently on December 6 version, so will be a good test.

1 Like
19

Trying to debug, it takes me into xtext territory, PersistenceStandaloneSetup, and then the debugger reports all kind of errors and shows a blank screen. I don’t think it’s able to debug this…

The errors from the debugger are like this, it’s strange how Eclipse can’t debug xtext, another Eclipse product, but whatever, it seems it must be figure out in some other way than using the debugger:

Exception processing async thread queue
Exception processing async thread queue
Missing system library
Exception processing async thread queue
Missing system library
20

What’s the content of thay file? Default has been removed from the syntax and you require a strategy for each item definition. Can it block because it fails parsing rhat file?