Error: Could not find or load main class Files... openhab2 as a service on Linux (see workaround at last posts)

[scaprile]

Hi there...
I don't think this is related to #112 nor #132
Just upgraded my installation yesterday to the latest snapshot. Service was running fine.
Now it does not start. Enabled debugging in wrapper conf, checked userdata/logs/wrapper.log, not much interesting data (to me) but:

DEBUG  | wrapper  | 2017/01/21 10:40:09 | Command[39] : -classpath
DEBUG  | wrapper  | 2017/01/21 10:40:09 | Command[40] : /home/scaprile/Projects/inProgress/openHAB/2/userdata/lib/wrapper/karaf-wrapper.jar:/home/scaprile/Projects/inProgress/openHAB/2/userdata/lib/wrapper/karaf-wrapper-main.jar
[...]
DEBUG  | wrapper  | 2017/01/21 10:40:09 | Command[52] : org.apache.karaf.wrapper.internal.service.Main
STATUS | wrapper  | 2017/01/21 10:40:09 | Launching a JVM...
INFO   | jvm 5    | 2017/01/21 10:40:10 | Error: Could not find or load main class org.apache.karaf.wrapper.internal.service.Main
DEBUG  | wrapper  | 2017/01/21 10:40:10 | Signal trapped.  Details:
DEBUG  | wrapper  | 2017/01/21 10:40:10 |   signal number=17 (SIGCHLD), source="unknown"
DEBUG  | wrapper  | 2017/01/21 10:40:10 | Received SIGCHLD, checking JVM process status.
DEBUG  | wrapper  | 2017/01/21 10:40:10 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
ERROR  | wrapper  | 2017/01/21 10:40:10 | JVM exited while loading the application.

Then I go ahead and see if those files are there:

userdata/lib/wrapper/karaf-wrapper.jar:      Zip archive data, at least v1.0 to extract
userdata/lib/wrapper/karaf-wrapper-main.jar: Zip archive data, at least v2.0 to extract

Then try to run them to see if there is some sort of a magic log that points me to the right direction:

$ java -jar userdata/lib/wrapper/karaf-wrapper.jar
no main manifest attribute, in userdata/lib/wrapper/karaf-wrapper.jar
$ java -jar userdata/lib/wrapper/karaf-wrapper-main.jar
Error: Invalid or corrupt jarfile userdata/lib/wrapper/karaf-wrapper-main.jar

Here, "java" is the same used by openHAB, 1.8.0_77
unzip successfully reads this .jar file and

$ file org/apache/karaf/wrapper/internal/service/Main.class
org/apache/karaf/wrapper/internal/service/Main.class: compiled Java class data, version 51.0
$ java org/apache/karaf/wrapper/internal/service/Main.class
Error: Could not find or load main class org.apache.karaf.wrapper.internal.service.Main.class

This is as far as I'm able to get.
Will appreciate some help from you guys.

[kaikreuzer]

Can you reproduce any problem with a "clean" installation, so that you can rule out that your update didn't mess anything up?

[scaprile]

Hi Kai, latest try was with everything clean but the conf/services dir.
Can try an extra clean later. (Lunch time here)

[scaprile]

Absolutely clean installation behaves the same way.
Maybe there's some new procedure I overlooked ? What I do is:
Unpack zip file, run start.sh, execute openhab:install-service, exit.
Edit service file, uncomment RUN_AS_USER=myusername, exit.
As root, run the service file with parameter 'start'.

[scaprile]

Perhaps I was ambiguous on my latest statement: a clean installation did not work either.
I discovered the installation requirements document and updated Java to 1.8.0_121.
The service still does not start, the error is the same.
The machine is a Centos 5 32-bit.
I could eventually test on a Centos 6/32 and a Centos 7/64 with a bit of effort; this shouldn't be related to an OS, should it ?

[scaprile]

Tried on freshly updated CentOS 7 with Java 1.8.0_121 and the service does not start, issuing the same error.

[qfluxlab]

Same problem with the windows service... fresh install, latest java. It ran fine forever, and broke when I upgraded to a new snapshot. This looks relevant: https://community.openhab.org/t/install-openhab-2-in-windows-10-as-windows-service/18375/6.

[scaprile]

@dynostatic : My config file has all those parameters and some more
No "works on my system", no "check this", nothing. I would debug it if a knew where to start, I have no clue how that missing class is supposed to be loaded. It doesn't even load manually out of the zip file and I can't spare the time to learn to design and debug JVMs...

[scaprile]

Well, the issue is by no means solved, but since I got no responses, I will close it. Perhaps if I later open it again I catch someone's attention...

[DigitalBites]

In my initial searches see you bumped into this issue as well so hopefully this helps someone code up the correct fix, there are a few ways to attack this.

The error you are getting is simple - this wrapper the team uses can't find the main class files for its libraries. "Error: Could not find or load main class org.apache.karaf.wrapper.internal.service.Main"

Reason: Incorrect configuration for the wrapper was defined by openhab.

So... I started digging into the /userdata/etc/openHAB-wrapper.conf

`#********************************************************************

Wrapper Properties

#********************************************************************
set.default.JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.x86_64/jre
set.default.KARAF_HOME=/opt/openhab/openhab-2.1.0-SNAPSHOT-20170217/runtime
set.default.KARAF_BASE=/opt/openhab/openhab-2.1.0-SNAPSHOT-20170217/userdata
set.default.KARAF_DATA=/opt/openhab/openhab-2.1.0-SNAPSHOT-20170217/userdata
set.default.KARAF_ETC=/opt/openhab/openhab-2.1.0-SNAPSHOT-20170217/userdata/etc

Java Application

wrapper.working.dir=%KARAF_BASE%
wrapper.java.command=%JAVA_HOME%/bin/java
wrapper.java.mainclass=org.apache.karaf.wrapper.internal.service.Main
wrapper.java.classpath.1=%KARAF_BASE%/lib/boot/*.jar <-- this little guy here (path) doesn't actually exist
wrapper.java.classpath.2=%KARAF_BASE%/lib/wrapper/*.jar
wrapper.java.library.path.1=%KARAF_BASE%/lib/wrapper/
`

It appears the team has refactored something some place as this file changed quite a bit from my last one but if you look above under "Wrapper properties" this entry pointed above uses KARAF_BASE. The libraries that are missing are actually in KARAF_HOME. It appears the %KARAF_BASE%/lib/wrapper/*.jar files (class file below) do actually exist and are the same file sizes as the ones in runtime & userdata so I left that as it was as I'm going to be lazy with this "patch" or fix.

You have two options:

1. update the openHAB-wrapper.conf to reference KARAF_HOME instead of KARAF_BASE or
2. what I did: just create a symlink -
   #pwd #/opt/openhab/openhab-2.1.0-SNAPSHOT-20170217/userdata/lib #ln -s ../../runtime/lib/boot boot

Hopefully this helps you out. I'll let the admins integrate a fix for it. I don't know how the config files are being generated and am not interested in learning that one :)

[scaprile]

Well, THANK YOU @DigitalBites , I find the java errors sort of misleading and couldn´t get beyond the class itself.
In my case I'm running the stable 2.0 and there is no lib dir under userdata so I just linked from there.
For other user's out there running the 2.0 release and wanting to run as a service:

$ pwd
/somewhere/openHAB/userdata
$ ln -s ../runtime/lib

I collaborate on many open source lists for libraries I use, either providing code or helping with support. In this case, I will let others deal with the admins. Enough for me.

[rberger]

By the way, this impacted startup on Mac osSierra as well. The ln solution worked there as well.

[piejanssens]

@kaikreuzer What is the official fix for the issue/workaround described by @DigitalBites?
(Same issue on Win10...)

[DomQuixote]

This issue is still not solved and messes up the service installation on Mac OS X High Sierra. I just spent two days installing and reinstalling, adapting plist files, etc etc. Finally found this thread. For me, this was an additional error after JAVA_HOME not being set in the wrapper.conf file. It now seems to work.

If this is an issue every user on Mac OS X will run into, it will deter 99% of them from using openHAB.

[kaikreuzer]

Where does our doc actually talk about using service wrapper for MacOS? On https://www.openhab.org/docs/installation/macosx.html, I cannot find anything about it.
Note that the service-wrapper is a feature of Apache Karaf, which seems to be broken there since long and not easy to be fixed afair. So the best solution for us would be to remove any mention of it from our documentation and rather come up with some "standard MacOS way" to start apps as a service in the background (however this works, but I am sure someone of you could figure it out and provide that information in the documentation).

[DomQuixote]

Not sure about where I found this.

On the other hand, in order to execute the process of service-wrapping, one has to call a specific option in the Karaf console called openhab:install-service that first does a lot of things and then explains quite detailed how to proceed for Mac OS X. It is not called generic:install-service, but specifically openhab:install-service, so my guess is that most people will think that this is managed by openhab.

The standard way of starting an app as a service would be by creating a plist file of some program, script or... wrapped service and installing it in LaunchDaemons. However, I have tried the way that was described somewhere in the documentation (?) which involved just creating a plist file that runs start.sh) but ran into a lot of problems. The install-service gave me a lot more confidence about the suggested steps and is, I think, the right solution, if only the three values that are missing / wrong are filled out correctly.

UPDATE Now I am not yet at the end of my struggles, as I can now manually run the wrapper but not with launchd, but I guess that is probably due to me or my plist file. Forum post to follow....

[p2made]

I hit this too. Brand new, first time install on High Sierra.

4.30 in the morning is no time for close inspection & debugging, so I'll be looking more closely after sleep, & update this accordingly.

For me installing on my Mac is for learning openHAB & I plan to run it on Raspberry Pi for actual use.

[flatsiedatsie]

Same here. Bad first impression..

[Sekenon]

openHAB2 2.4.0 (on Windows WHS2011) still has this issue.
Modifying openHAB2-wrapper.conf as described fixed it:
wrapper.java.classpath.1=%KARAF_HOME%/lib/boot/*.jar

[mkormendy]

@scaprile You should re-open this issue until it is fixed or addressed in the documentation and the configs and service scripts corrected.

I had the following two issues on MacOS High Sierra, as mentioned by others now:

1. JAVA_HOME being set to null in the openHAB-wrapper.conf file found at \Your-OpenHab-Path\userData\etc\openHAB-wrapper.conf
2. Confusing %KARAF_BASE% with %KARAF_HOME% in the wrapper.conf file

Clearly the applied symlink fix works best per the above comment here, but the wrapper configuration file should be fixed as well as the install-service script corrected to locate and set the JAVA_HOME path.

[scaprile]

@mkormendy ... I'm sorry I don't have the time to check right now, regarding openHAB I'm on "user mode". I've since then successfully upgraded and I'm now running 2.4, No issues on upgrades. The link is still there, however.
Since this has been related to Linux and have not raised much interest, I suggest you open a separate issue for MacOS. As far as I can tell JAVA_HOME et al had been correctly set in userdata/etc/openHAB-wrapper.conf when issuing openhab:install-service at the prompt.
My java version is openjdk 1.8.0_144, for what it's worth.

[mkormendy]

Well I have it running, but I had to perform the fixes as indicated in this thread.

I as well, am on openHAB 2.4 (macOS download).
I am running openjdk version 1.8.0_163.

Upgrading openHAB shouldn't overwrite the config file if it exists already when attempting to use the script to set it up again as a service. Once you've set it up and fixed/filled-in the issues in it, any further upgrades shouldn't have a problem and will use the existing config file I believe.

I will put together a ticket to address this and possibly create a pull-request for the documentation and as well an update to the config file and mac-specific plist file.

[scaprile]

I happen to have copies of old installations and run a diff on openHAB-wrapper.conf. It is changed by upgrades.
I also remember reading a notice (when setting up the service) that I should remove that file to have some benefits... I didn't... I could try renaming it and try on my next upgrade, but I'm afraid am very short of time to have fun.
Looking at the diff my bet is it is not overwritten but they do add new stuff. However, I didn't look very carefully.

[Jitterer]

well... openHAB 2.5.1 after years still has the same wrong wrapper-conf.
I still need to manually workaround like described from DigitalBites because of the wrong path in wrapper.java.classpath.1

[Jutulind]

Can confirm. This issue is still there. Wrong classpath, took me 30 minutes to track down.

Actual problem seems to be in:
wrapper:install --name "openHAB2" --display "openHAB2" --description "openHAB 2 Service"
command that DOES NOT create main jar class under userdata.