Systemd service should use /bin/karaf instead of start.sh

[BClark09]

Closes #70

Signed-off-by: Ben Clark ben@benjyc.uk

[BClark09]

@ThomDietrich if it helps for testing, the above changes are available as a full pacakge in the linuxpkg-testing repo:

echo 'deb https://openhab.jfrog.io/openhab/linuxpkg-testing unstable main' | sudo tee /etc/apt/sources.list.d/openhab2.list

[BClark09]

OPENHAB_USERDATA=WHEREAMI

Before PR:

After PR:

Seems to have gone well!

[ThomDietrich]

Excellent! I'm sadly not able to do any tests today. I'm curious how the error would look like if there is no java runtime available

[BClark09]

There's a weird issue with this:

When a program managed by systemd sources a script, the stout buffer from that script seems delayed. In this case, when karaf calls our setenv script the echo 'Java version higher than 1.8...' does not get the chance to print when exit 1; follows.

To see this error message in systemd, we would have to edit 'setenv' to output with:

echo "Error message" && /bin/true

Which is otherwise completely redundant.

[ThomDietrich]

@BClark09 If it is like you suggested and the buffered stdout is cut off too early at the exit, did you find a discussion on the issue? This one looks alright: http://systemd-devel.freedesktop.narkive.com/suwZf7s7/unbuffered-stderr-for-my-systemd-service

Your proposed solution does work because the otherwise useless && /bin/true will delay following commands? Is there a cleaner and more intuitive way to solve this? sd_notify would be an option for systemd. Another option might be sleep but that's hack'y...

[BClark09]

There are a few scattered around (this for example), I think this is the systemd bug to watch for this issue though.

[BClark09]

I think this is okay to merge now. I'll wait a bit for feedback in the above thread to see if the ulimit restriction has been adjusted.

[ThomDietrich]

Why?

[BClark09]

It seemed un-natural at it was. My intention was to capitalise the S and H in Smart Home (as it is in the docs), but I must have misplaced that.

[ThomDietrich]

I also wanted to do that a few months ago but got scolded by Kai for it.

http://docs.openhab.org/images/logo.png

[ThomDietrich]

openhab/openhab-distro#271 (comment)

[BClark09]

I see... I'll change it back then.

[ThomDietrich]

Should we list the options here?

[BClark09]

I wasn't so sure, options for karaf are:

clean   - Deletes $KARAF_DATA contents (/var/lib/openhab2)
debug   - Turns on java debugging options
status  - Checks if running
stop    - Stops instance
console - ???
server  - Starts remote shell and runs the karaf server
daemon  - Same as server, extra exec and return details.
client  - Starts the client to an existing instance

Out of them, we could really only recommend using daemon, debug or debug daemon with systemd. Definitely don't want to mention clean!

[ThomDietrich]

Agreed.

[BClark09]

@kaikreuzer, @theoweiss, just an FYI: I noticed there was some discussion at openhab/openhab-distro#138 about how to start using systemd. I have changed this to use runtime/bin/karaf daemon so that systemd recognises java as the main process to follow. It is also the recommended way using the karaf service template by the looks of things.

Is there any reason, or can you remember any reason for this being a bad idea? Tests on Debian and Fedora have worked well, so will merge this PR soon.

[kaikreuzer]

I am not aware of reason against it, but @theoweiss is indeed probably the much better person to ask about it :-)

[ThomDietrich]

@BClark09 Instead of the && /bin/true trick we could use systemd-notify/sd_notify. Did you look into them?

[BClark09]

I couldn't find a way of incorporating it reliably, it seems to suffer from the same race condition.

Also, should we really add platform specific Linux commands to openHAB's start scripts?

[ThomDietrich]

I thought about it and couldn't see a reason why not. Of course one would need to properly check for systemd beforehand.

it seems to suffer from the same race condition

Well nice...

[BClark09]

Actually, I may have been wrong in that, was looking in the wrong place. The systemd service needed a bit of tweaking to be of "notify" type.

Unfortunately, this still isn't a solution, openHAB would need an implementation of sd_notify to pass down that the service has started successfully. Otherwise, the service start command would keep waiting for one and timeout.

[ThomDietrich]

You mean this would need to happen inside openHAB or Karaf, not inside the bash script!?

[BClark09]

If you're using sd_notify, then you'll need to pass down a message that the service has started successfully, which should only happen inside the java process started by Karaf if you want to certain that everything is working correctly.

[BClark09]

To summarise:

• This PR makes sure that some information is available.
• Additionally, the service now has a larger file limit as suggested by the Karaf template.
• Since I've re-enabled automatic restarting (with some delay now) these messages only appear when the user uses journalctl -u openhab2 -b (report all openhab2 service messages since last boot). This is what we should suggest to users for debugging.
• The service still requires some editing of setenv to obtain all output.
• I've got to stop pressing the close button instead of the comment button.

I'd suggest we merge now and I can make a PR in the distro if using && /bin/true is an acceptable workaround.

[theoweiss]

Sorry guys for not participating in this discussion but remodelling our new house and working for my paid job is still eating my whole time. May be I'm back in late autumn. @BClark09 is doing a great job here!!

[BClark09]

No problem @theoweiss! Hope it's all going well!