[SOLVED] Problem with Openhab 2.3 and systemd failing after upgrade

Setup, Configuration and Use Installation
1
  • Platform information:
    • Hardware: VMware ESXi VM on Dell Poweredge
    • OS:Ubuntu 16.11LTS
    • Java Runtime Environment: Java™ SE Runtime Environment (build 1.8.0_77-b03)
    • openHAB version: 2.3 (upgraded from 2.0 using upgrade script. 2.0 was a complete standalone and not a repository type installation)

Hi…

I seem to have the exact problem as here:
https://community.openhab.org/t/solved-openhab-2-3-and-systemd-error-executing-command-java-lang-nullpointerexception/45585/5

2.0 worked pretty flawlessly. Upgraded to 2.3 with the upgrade script, and when starting OpenHAB manually with start.sh, all is well! It ran for 3 days not a problem. I try to use the same openhab.service file that I used with 2.0, and the exact problem as in the link above happens.
->sudo systemctl start openhab
->sudo systemctl status openhab - all seems ok for a minute, light is green, logs start to generate, and startup rules complete. Then it looks like someone hit CONTROL+D in the console as it starts shutting down with no indication as to why in the logs.
->sudo systemctl status openhab - now shows white lite with:

Active: inactive (dead) since …

Last line is a clue:
Jun 22 18:25:41 serverL1 start.sh[23547]: openhab> Error executing command: java.lang.NullPointerException

At one point I was seeing:
Jun 22 18:01:33 serverL1 systemd[1]: [/lib/systemd/system/openhab.service:13] Executable path is not absolute, ignoring: kill

But this seemed to go away.
I have a service file that calls start.sh directly, and its worked since 1.7.

[Unit]
Description=Starts and stops the openHAB Home Automation Bus
Documentation=http://www.openhab.org
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
Environment=OPENHAB_STARTMODE=daemon
GuessMainPID=yes
User=jim
ExecStart=/opt/OpenHAB2/start.sh
ExecStop=kill -SIGINT $MAINPID
Restart=on-failure
WorkingDirectory=/opt/OpenHAB2

[Install]
WantedBy=multi-user.target

As you can see it runs as user jim, and I did RWE recursive permissions on the whole OH directory, so I don’t see how it could be a user/permission issue since that has all been the same since way back in 1.7.

I’ve been through these threads:
https://github.com/openhab/openhab-linuxpkg/issues/70
and commented out:

karaf.shell.init.script = ${karaf.etc}/shell.init.script

from this thread:
https://community.openhab.org/t/initialization-problem-with-openhab-2-2-build-1017-on-windows-10/33407/21

And nothing seemed to have an effect on it.

It boggles the mind how it can run perfect from start.sh as user jim, and not the service file which calls the same thing! The extra line you see in my service file setting the environment was not there before, I added that because someone said it fixed theirs, and left it so you can see it didnt work for me.

Any ideas or a hint where else I can check to get more info on the problem?

Best regards,
Jim

2

Support withdrawn.

3

you are setting the OPENHAB_STARTMODE to ‘daemon’ but then the start script does not use this variable. In my example i start karaf directly and add the variable as an parameter to the end.

to get it working for you, just add “daemon” directly after start.sh like

ExecStart=/opt/OpenHAB2/start.sh daemon

and as a stop script you should use

ExecStop=/opt/OpenHAB2/start.sh stop

4

Holger!
Dude, you are the best! Fixed - thanks so much!

Hope this helps someone else too, because I sure cant find that suggestion anywhere.
I guess I should have scrutinized that start.sh file closer, but running it manually worked, so I didn’t honestly suspect that to be the problem.

Rich:
I’ve used this method of install since 1.7. I see no reason to change - it’s easier to back it up in one shot with a script is the main reason, second it’s easier to clone it to my laptop for some testing before I deploy a big change, and third I’m a creature of habit. Further, it’s supported and very common installation type therefore I shouldn’t have to change! It should work properly this way just like it always used to-its a absolute nonsense to switch because of that.

5

Support withdrawn.

6

Hey guys…

I recently upgraded my OS from Ubuntu 16.04 LTS to Ubuntu 18 LTS
I have installed Openhab 2.3 Stable version this is installed in Ubuntu 18
When I checked the status this is what I got:

openhab2.service - The openHAB 2 Home Automation Bus Solution
Loaded: loaded (/lib/systemd/system/openhab2.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2018-06-25 23:04:15 SAST; 1h 6min ago
Docs: http://docs.openhab.org
Process: 9787 ExecStart=/opt/openhab2/start.sh server (code=exited, status=255)
Main PID: 9787 (code=exited, status=255)

desktop systemd[1]: openhab2.service: Service hold-off time over, scheduling restart.
desktop systemd[1]: openhab2.service: Scheduled restart job, restart counter is at 53.
desktop systemd[1]: Stopped The openHAB 2 Home Automation Bus Solution.
desktop systemd[1]: openhab2.service: Start request repeated too quickly.
desktop systemd[1]: openhab2.service: Failed with result ‘exit-code’.
desktop systemd[1]: Failed to start The openHAB 2 Home Automation Bus Solution.

The Java that is running here is:
openjdk version “10.0.1” 2018-04-17
OpenJDK Runtime Environment Zulu10.2+3 (build 10.0.1+9)
OpenJDK 64-Bit Server VM Zulu10.2+3 (build 10.0.1+9, mixed mode)

Please help…:tired_face::tired_face::tired_face:

7

downgrade to Java 8

8

I can only assume your response was a joke. At any rate, it was quite amusing - thanks for the laugh!

I upgraded. It’s broken. But “I see no reason to change”.

Then why ask for help?

I’m sorry, did I put that in one sentence nor imply that was the gist of my post? I don’t believe I did. So you take what I said and turn it into a bazaar absolute - nice. I asked for help with the service file, not to redesign my installation type away from a supported system that works that a significant number of people are still using. You asked:

why you are not using apt to install OH which will install it’s own .service file

And I gave you the reason why-simple as that. It’s a supported installation type - why should I change methods?

You mean like the backup and restore script that ships with OH now in the bin folder?
…
Again, like you could do with the backup and restore script that comes with OH?

I wouldn’t know - my installation of of 2.3 that has these scripts was not successful until Holger was helpful enough to assist, and they never used to be there, so again I wouldn’t know. I still find it more useful and faster to tar the whole thing than bits and pieces. If you look at the content of those scripts that’s all they are doing anyway.

It is unreasonable for you to think that you can upgrade a system and expect to never have to change anything.

I’m sorry, again did I say I didn’t expect to change ANYTHING? I don’t believe I did.

… if you look at the installation instructions 1 for this common installation type, you will see that there have been changes made to the .service file, or at least there are lots of differences from the one you have been using.

Right, BUT I had tried this method before, and it didn’t work for me, nor other people on this forum (at least one other post…) And this person went back to calling the script directly, just like I was trying to do. What I didn’t understand is why it worked as a solution to them and not for me - it could be only that he omitted the overloads to the script in the post.

Again, no one said you should have to switch from a manual installation. But when something stops working after an upgrade, you SHOULD go and review the docs to see if something about the system changed and you have to accommodate for that.

Right, I did, and changing just the service file did not work for me - nor did it for other people. Of course you SHOULD, but nowhere in the docs did I find this suggestion, hence my post.

Or just don’t upgrade at all. If you don’t want to change that certainly solves that problem.

Again, bazaar absolute. I never said I didn’t want to change ANYTHING, I didn’t want to change the INSTALLATION TYPE away from something that is fully supported.

You should be a car salesman. :slight_smile: I can see someone taking their car for trade, and you trying to sell them a truck just because “we offer that now”.

9

Hi Nduzi

My problem was about a upgrade on OpenHAB, not the OS.
Nevertheless, OpenJDK is mentioned to have some compatibility issues:


Try pulling off the openjdk unless you have a specific reason to keep that and use java 8. I you must keep openjdk, put java in parellel and specifically call it with the scripts - There is a section on the environment somewhere that can help you (I cant remember where I saw it, but should be easy to find).

I have it runnung on both 16.04LTS and 18LTS too with “real” java with no problems beside the problem starting it from the service.

I assume yours doesn’t even start by calling ./start.sh directly either?
If changing/forcing specific java does not fix it, can you tell us if it’s generating logs?

10

Thank you…

I simply just installed Java 8 and chose it as default and now it’s perfectly Fine

Thanks @Dim

11

Thanks @jimkernsjr

I simply installed Java8 and Set it as default…Everything is working now…

But then I have another problem…
I backed up the openhab configuration files and user-data, as specified in the openhab documents
I restored the same zip file and nothing has happened, the files I see have been restored, but the Habpanel configuration that I have is not there, neither are the items, or the things specifications, basically nothing is working…

Also more information, the backed up data is from openhab 2.2 and Restoration was on openhab 2.3

How do I deal with that…?

12

Support withdrawn.

13

start from scratch. Bring back files one by one in the conf folders (/etc/openhab2/...)
The HABPanel config is stored in userdata /var/lib/openhab2/config/org/openhab/...

14

Hey Nduzi…

Did you try Dim’s suggestion below?
It should be easy to just move as he says. Move …/conf. then 90% of it will be ok.
After checking, then move HABPANEL.

If not, what about copying the openhab installation to the new 18.04 then run the upgrade scripts?

I’m having a hard time to understand exactly where you are at with those statements:

I recently upgraded my OS from Ubuntu 16.04 LTS to Ubuntu 18 LTS
I have installed Openhab 2.3 Stable version this is installed in Ubuntu 18

…afterwards you ask about backup and restore.
If you upgraded (same machine) the OS, OH should still be be on there (as you say you have backups, I can only assume you had OH on 16.04) But then you say you install OH2.3, so I don’t understand where the backups came from.

Let us know how you got where you are at and the installation type and it will be easier to suggest a plan.

Best Regards,
Jim

15

OK, so your responses were a joke…got it.
Since bantering back and forth and continuing the “you started it” war you started is not beneficial to this thread nor the forum, I wont waste my time any longer with your nonsense - since it’s apparent you have way more time on your hands than I do. So go ahead and get the last word in, since obviously your ego wouldn’t let you not do that.

16

Very well then. Consider anything I said as withdrawn. You will not need to worry about help from me again. At least I didn’t throw personal insults.

17

Hey guys :sweat_smile:

I just got back at this, and turns out that I have been restoring to the wrong folder
Since I Installed openhab 2.3 manually, the file that I was supposed to return it to is /opt/openhab2 instead of /etc/openhab2

And so I did the write thing, and everything returned to normal…
Thank You

1 Like