" You should now follow the first installation procedure" -
there is no link to installation procedure. I have tried both doing nothing and setting up the first environment.
In any case, when I get to the installation of the service part, everything seems doing okay except that the service fails to run.
Wrapper.log says:
INFO | jvm 4 | 2020/12/17 16:28:11 | -Djava.endorsed.dirs=C:\Program Files\Zulu\zulu-11\jre\lib\endorsed;C:\Program Files\Zulu\zulu-11\lib\endorsed;C:\openHAB\runtime\lib\endorsed is not supported. Endorsed standards and standalone APIs
INFO | jvm 4 | 2020/12/17 16:28:11 | in modular form will be supported via the concept of upgradeable modules.
INFO | jvm 4 | 2020/12/17 16:28:11 | Error: Could not create the Java Virtual Machine.
INFO | jvm 4 | 2020/12/17 16:28:11 | Error: A fatal exception has occurred. Program will exit.
ERROR | wrapper | 2020/12/17 16:28:11 | JVM exited while loading the application.
STATUS | wrapper | 2020/12/17 16:28:16 | Launching a JVMā¦
INFO | jvm 5 | 2020/12/17 16:28:16 | NOTE: Picked up JDK_JAVA_OPTIONS: --add-reads=java.xml=java.logging --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED --patch-module java.base=lib/endorsed/org.apache.karaf.specs.locator-4.2.7.jar --patch-module java.xml=lib/endorsed/org.apache.karaf.specs.java.xml-4.2.7.jar --add-opens java.base/java.security=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.naming/javax.naming.spi=ALL-UNNAMED --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
INFO | jvm 5 | 2020/12/17 16:28:16 | -Djava.endorsed.dirs=C:\Program Files\Zulu\zulu-11\jre\lib\endorsed;C:\Program Files\Zulu\zulu-11\lib\endorsed;C:\openHAB\runtime\lib\endorsed is not supported. Endorsed standards and standalone APIs
INFO | jvm 5 | 2020/12/17 16:28:16 | in modular form will be supported via the concept of upgradeable modules.
INFO | jvm 5 | 2020/12/17 16:28:16 | Error: Could not create the Java Virtual Machine.
INFO | jvm 5 | 2020/12/17 16:28:16 | Error: A fatal exception has occurred. Program will exit.
ERROR | wrapper | 2020/12/17 16:28:16 | JVM exited while loading the application.
FATAL | wrapper | 2020/12/17 16:28:16 | There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up.
FATAL | wrapper | 2020/12/17 16:28:16 | There may be a configuration problem: please check the logs.
STATUS | wrapper | 2020/12/17 16:28:16 | <-- Wrapper Stopped
I have checked and the folders under C:\Program Files\Zulu\zulu-11 do not exist.
Tried to create them, does not help.
Donāt know how to fix this, any idea is appreciated.
Thanks
Iām not sure what thatās supposed to mean either. But if you can bring up localhost:8080 in the browser, openHAB is installed at that point so you can move on to configuration.
Did you install Java first? Which version of Java did you install? Does it run when you execute start.bat manually? Did you set the path and JAVA_HOME environment variables to the actual location where Java was installed?
Itās been a long time but I recall that one used to have to restart explorer.exe or log out and log back in in order for Windows to pick up changes to environment variables in the session. Have you donāt that?
NOTE: I donāt exepect you to have known to do all these things, Iām just trying to figure out what youāve tried.
NFO | jvm 5 | 2020/12/17 16:28:16 | Error: Could not create the Java Virtual Machine.
INFO | jvm 5 | 2020/12/17 16:28:16 | Error: A fatal exception has occurred. Program will exit.
ERROR | wrapper | 2020/12/17 16:28:16 | JVM exited while loading the application.
Also make sure that you installed the correct Java architecture - there is 32bit and 64Bit for Windows.
Sorry for the delay. There appears to be an annoying limit imposed on the qty of posts a new user can make the first day. No comments.
Yes, I am sure sureā¦
Installation steps:
I installed zulu11.43.55-ca-jdk11.0.9.1-win_x64.msi, so the architecture should be correct.
set JAVA_HOME to C:\Program Files\Zulu\zulu-11 (this is different from doc and was causing the error I mentioned in the other thread - issue being that installation of Zulu doesn not replace the old jre folder, uninstallation of the jre does not remove physically the files in the folder , so I changed the JAVA_HOME path to the Zulu path and deleted the old jre 1.8 .0_271 folder which was created during yesterdayās installation of OH2.5 [ā>>see what I meant about instructions for a clean install⦠I knew it⦠]
I followed the instructions step by step,
ā launched start.bat->no prob
ā opened localhostā>I get a set admin username and password, I set it and got to this page
ā>>ok, I get the confirmation of Setup complete and the other text as per installation webpage screenshot
ā> shutdown with logout -->>ok
ā updated C:\openHAB\userdata\etc\openHAB-wrapper.conf as per instructions
ā opened elevated prompt and launched C:\openHAB\userdata\bin\openHAB-service.bat install net start "openHAB" as per instructions
result: service says⦠starting, then crashes.
In the command windows I read
C:\WINDOWS\system32>net start "openHAB"
The openHAB service is starting.................
The openHAB service could not be started.
A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.
The wrapper.log is saying STATUS | wrapper | 2020/12/17 17:33:42 | Launching a JVMā¦
INFO | jvm 1 | 2020/12/17 17:33:42 | -Djava.endorsed.dirs=C:\Program Files\Zulu\zulu-11\jre\lib\endorsed;C:\Program Files\Zulu\zulu-11\lib\endorsed;C:\openHAB\runtime\lib\endorsed is not supported. Endorsed standards and standalone APIs*
INFO | jvm 1 | 2020/12/17 17:33:42 | in modular form will be supported via the concept of upgradeable modules.*
INFO | jvm 1 | 2020/12/17 17:33:42 | Error: Could not create the Java Virtual Machine.*
INFO | jvm 1 | 2020/12/17 17:33:42 | Error: A fatal exception has occurred. Program will exit.*
ERROR | wrapper | 2020/12/17 17:33:42 | JVM exited while loading the application.*
As mentioned above
What is even more surprising is that I can launch OH using start.bat and the environment seems to be working fine. Itās just the service which cannot start?! Strangeā¦
It greatly reduces the amount of spam we have to deal with. Itās pretty standard for more forums. If itās a problem, I can bump you up to a regular user.
Unfortunately I canāt help with that. Itās probably 15 years now since I last tried to get a Java program running as a service on Windows (NT at the time).
But the fact that you got it working with the start.bat file means that at least Java and the openHAB program itself is working.
But hereās the problem, what about those users who already have Java installed for other reasons? If we tell them to go remove old versions of Java that they need for other reasons then we get just as much grief that we broke their system. It is absolutely no problem to have more than one Java installed at the same time. Iāve had up to a dozen at one point. What matters to openHAB is that the JAVA_HOME path points to the one you want openHAB to use.
For a one liner like that itād be even better to clikc on the āEdit this page in GitHubā and add the sentence yourself. One liner fixes like that donāt necessarily need an Issue. Bigger changes like adding a whole new section though should have an issue.
Then Iām confused about what you are proposing. It sounded like you are proposing adding a change to the docs. There really isnāt anything that OH core can do about any JVM issue. Either Java is installed and he JAVA_HOME variable is set, or itās not and OH wonāt work.
first the problem (I solved) of the error mentioned in the other thread yesterday, caused by the Java_home environment variable. I suggest that the documentation is completed updating the screenshot + adding that note
second topic is the crash of the Windows service - the core subject of this post- I suppose that if the service doesn not start but the environment works it might be an issue with the development of the service. The statement in the log ...is not supported. Endorsed standards and standalone APIs in modular form will be supported via the concept of upgradeable modules.* sounds like a software develoment issue to me, not a Java installation one. Iāll try to escalate to the development team, I think.
I still donāt know that this is something that is actually part of openHAB. The core developers are probably not going to know anything about that. In fact I think that is implemented by the Karaf project upon which openHAB runs, not by openHAB itself. You might look at the Karaf forums and github to see if anyone else has reported similar problems.
In point of fact, I think itās actually still a documentation problem. Itās most likely this line thatās causing the problem.
the lines causing the proble are
wrapper.java.additional.8
and
wrapper.java.additional.9
if you remove 8 you get the following error
INFO | jvm 5 | 2020/12/18 00:55:10 | -Djava.ext.dirs=C:\Program Files\Zulu\zulu-11\jre\lib\ext;C:\Program Files\Zulu\zulu-11\lib\ext;C:\openHAB\runtime\lib\ext is not supported. Use -classpath instead.
if you remove them both the service start, but the ui is incomplete. so it appears to be an issue with conf - maybe, supposing there is a feasible way for the current code to properly interface jvm with the same parameter set.
on this I respectfully disagree.
A user expects that the sw development team puts together a set of tools, a compiled code and a configuration set which works together to deliver a functionality.
If they suggest to use Zulu11 and they donāt make the compiled code and/or the configuration compatible, the ball is in their OH court.
Now, three days of attempted troubleshhoting. Causes so far is incomplete documentation and -probably-software development issues.
Letās see what they reply. If there is no solution Iāll call it a day as, for me, OH3 is not ready for use, and Iāll roll back without remorse to OH2.5
Well, this is an open source project. in my opinion thatās an unreasonable expectation. Particularly for a project as large and complex as openHAB. There are too many parts, too many variables and and too many options. OH isnāt a software application, itās a development platform upon which users develop their home automation application.
We can barely keep up with docs for the stuff we actually wrote ourselves. If you require us to document all the third party stuff as well we may as well pack up and give up. Itās never going to happen.
But itās not a core code problem. That line in the service file that only exists in that documentation page needs some sort of update. The fact that you can run it using start.bat proves itās not a problem with the software itself. The core developers are not going to know anything about that. As I said, none of them run on Windows.
The problem here is in the docs. Youāll either need to find someone who knows Windows service files and Java or figure out that problem yourself. I canāt help. I donāt know anyone who can help. But I do know enough to know that the OH is working since it works with start.bat.
Thanks. Could you please nonetheless have a look after Windows install instruction to get them checked before OH3 release ? Iād think noone else will do.
@rlkoshak there are therefore two major changes required in the page of the installation steps for windows to make OH3 work in Windows.
The note about the JAVA_PATH to be set to the Zulu installation folder (*) (here) and, most important,
the text in the section describing the change to the openhab-wrapper.conf has to be updated as indicated in the post linked above(here).
Not sure who should officially take in charge this. Itās not cosmetics.
(*) keeping in mind your remark of different JAVA environment which sometimes are required to run on the same machine, I am not sure if a OH_JAVA_PATH should be defined instead, cascading the change to the .conf files using that environment variable
Itād be awesome if you gave it a shot. If not itāll have to wait until after I write a couple more pages for the getting started tutorial before I can get to it (sometime next week I think). Iāll see if there is a way to move faster. This does need to get fixed asap. I can help with logistics. Even if you just make the changes and need me to check in the changes.
The note about JAVA_PATH is pretty straight forward and you can probably do it in the browser without needing to clone the repo and mess with git directly. I havenāt looked at the changed needed for the service.
Ok, never done before⦠so steps are clone repository, modify the file⦠and then?
-OK forget it, Iāll read the GIThub doc too and end up with a pull request (I guess?!)