I am on new and faster Windows 11 hardware and experience the following behavior.
Every time a restart the MIniPC openHAB starts but only till Startlevel 50. Higher levels are not reached. Everything seems to work fine, even STartLevel 100 got not ticked.
Every time I quit OH and start again, StartLevel is reached within 2 minutes.
This behaviour is very consistent. I feel I have a Azul Jav WarmUp problem.
Once I succeeded to get it fully up after a fresh boor by starting UniFu netwerk server which also runs on Azul Java) and waiited 2 minutes. Then OH started fully
I don’t know how previous OH versions would have behaved because this is new hardware.
Who has a solution? I checked out Azuls NowReady mechanism but could not get it to run.
I checked both logs of the good and bad startup but no errors visible, it only stops continuing with increasing the startlevels. Timing of events happening are also more or less the same. No extra or missing logs on both sides until after Startlevel 50 has reached.
Are you using any Graal add-on (JavaScript- or Python scripting)? If so, try to uninstall those and see if the problem goes away.
Generally, OH doesn’t work so well on Windows because very few devs test it on Windows. Most things are the same, but Windows has one particular behavior that often causes problems for developers that only use/test on Linux/macOS: unlike the others, Windows has file locking. That means that a file must be closed after being opened before another process can open it (if it’s opened in “exclusive” mode, which is typically the case if you might want to write to the file). Since the other OSes don’t have this, you can overwrite or delete files from one process that is being worked with by another process. It’s a great way to corrupt files, but that’s how it is.
As a consequence, there is lots and lots of code, not just in OH, but in libraries used by OH, that “doesn’t work so well” with Windows because they don’t clean up their file handles, and leave files locked. This makes some code work differently on Windows, because you get errors where you otherwise wouldn’t, and if nobody has cared to handle this, it breaks.
Another consequence is that for every file access, the OS must first consult the “locking table” to see if the file can be accessed. This slows down file handling (just the opening, but if you have many small files, it adds up) in Windows. What slows down file handling even more is the stupid, forced antivirus scanning that takes place automatically. I’d really recommend that you exclude any folders that OH uses from scanning, because disabling the scanning will only work for a few hours.
This difference in “file access speed” can make things behave differently than they do on other OSes during startup, which can trigger hard-to-find timing bugs. My guess is that this is what you’re actually seeing, a timing bug, that you experience because of your combination of hardware and OS that most others don’t experience. I’m 99% sure that there are such “timing issues” in the Graal add-ons, which is why I think it would be useful to see if the behavior goes away without those installed.
I excluded process:java.exe, folder:Zulu and folder:openhab from Realtime scanning and now i started normal and reached StartLevel 100 within 2 minutes. Nice.
I’ll experiment further to see which exclusions are needed and which to remove.
It still means there’s a timing bug in there, but at least you can avoid it. These are really, really hard to pin down, and Graal was my “best guess”. Since it’s not involved, I don’t have any idea what could be the cause. It might be that a log from when it fails could shed some light, but perhaps you’re content that it works and don’t want to spend more time/effort at it?
I think I leave it this way. Have put a lot of time last weeks in the startup behaviour.
One thing I noticed though; Startlevel 50 is reached before startlevel 30. And this happens all the time, with good startup till 100 and bad startup till 50. Curious.
