Thanks. I’m happy to heklp but I dislike mixing installation methods.
Aren’t snapshots right there to handle this ?
Remember there’s also the testing repo for those who want a little more safety.
Woohoo!
Sadly I don’t have the spare cycles to test this immediately but at the end of next week I should have some time. I’ll come back and give the Docker images a test run.
To me this is the same as providing a test JAR in a PR (or IoT Marketplace) and people helping out with testing before code gets merged.
So far I couldn’t find any major issue myself. Since this looks too good to be true, maybe others can help finding some. 
Hopefully you can help testing the merged PR in the 2.4.0-SNAPSHOT by then. 
1 Like
I’ve built an unsigned and experimental .deb package if you’d like to test?
I’d advise against trying to use the directory above as a repo (as this is where the build process is tested first and you may get very broken packages from it).
Simply download and install with:
wget https://openhab.jfrog.io/openhab/linuxpkg-testing/pool/main/2.4.0~20180912202921/openhab2_2.4.0~20180912202921-1_all.deb
dpkg -i ./openhab2_2.4.0~20180912202921-1_all.deb
It will upgrade an existing openHAB installation, and be replaced by any new snapshots (without Karaf 4.2.1) that are released after this time.
1 Like
Thanks Benjy. Installed it but seems that package broke my delayed rules processing at startup. Didn’t investigate but seems my rules files were processed right from the start.
[10:38:56] root@openhabianpi:/home/openhabian# cat /etc/systemd/system/openhab2.service.d/override.conf
[Service]
ExecStartPre=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.rules" -exec /usr/bin/rename.ul .rules .x {} \\;'
ExecStartPost=-/bin/sleep 180
ExecStartPost=-/bin/bash -c '/usr/bin/find ${OPENHAB_CONF} -name "*.x" -exec /usr/bin/rename.ul .x .rules {} \\;'
TimeoutStartSec=300Hmm, not sure how this could have happened. The systemd scripts haven’t been changed. Does this still occur each time you start up openHAB?
No, re-tested and it was fine now. I did a systemctl daemon-reload, possibly that wasn’t part of your package but is for the snapshot ones ? Just guessing, though.
Other than that, the Karaf part LGTM.
1 Like
Cool, so @wborn seems to have done a fantastic job, so let’s merge and make it available in the latest snapshot builds to even more testers 
.
1 Like
Does this mean that the limitation to only using Java 8 goes away and the docs need to be updated or are there other libraries or ESH/OH code that still requires no later than Java 8?
I want to be sure the docs get updated if we can use the newer Javas now.
As discussed on the PR, the Karaf upgrade is a prerequisite for newer Java versions, but upgrading Karaf does not mean that we can immediately declare openHAB working with newer Java versions. So short answer: No, we stay with Java8 for now.
Instead of hopping on Java 9, the better plan might be to only go for LTS releases such as the upcoming Java 11 - see also https://www.azul.com/think-moving-jdk-9-sometime-next-year-think/.
1 Like
Thanks for helping out with testing everyone!
Karaf 4.2.1 is now available in the latest 2.4.0-SNAPSHOT (build #1362). 
3 Likes
After logging out with logout from openhab-cli console I get:
2018-09-26 18:41:01.611 [WARN ] [org.jline ] - Failed to save history
java.nio.file.AccessDeniedException: /home/openhab
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:674) ~[?:?]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) ~[?:?]
at java.nio.file.Files.createDirectories(Files.java:767) ~[?:?]
at org.jline.reader.impl.history.DefaultHistory.save(DefaultHistory.java:132) ~[17:org.jline.reader:3.9.0]
at org.jline.reader.impl.history.DefaultHistory.add(DefaultHistory.java:277) [17:org.jline.reader:3.9.0]
at org.jline.reader.impl.LineReaderImpl.finishBuffer(LineReaderImpl.java:944) [17:org.jline.reader:3.9.0]
at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:594) [17:org.jline.reader:3.9.0]
at org.apache.karaf.shell.impl.console.ConsoleSessionImpl.readCommand(ConsoleSessionImpl.java:439) [14:org.apache.karaf.shell.core:4.2.1]
at org.apache.karaf.shell.impl.console.ConsoleSessionImpl.run(ConsoleSessionImpl.java:397) [14:org.apache.karaf.shell.core:4.2.1]
at java.lang.Thread.run(Thread.java:748) [?:?]
Snapshot #1372 apt install on Ubuntu 18.04 LTS, so the directory /home/openhab should never be called because it does not exist on an apt install …
Any ideas?
sihui@nucopenhab:~$ openhab-cli info
Version: 2.4.0-SNAPSHOT (#1372)
User: openhab (Active Process 5173)
User Groups: openhab tty dialout audio
Directories: Folder Name | Path | User:Group
----------- | ---- | ----------
OPENHAB_HOME | /usr/share/openhab2 | openhab:openhab
OPENHAB_RUNTIME | /usr/share/openhab2/runtime | openhab:openhab
OPENHAB_USERDATA | /var/lib/openhab2 | openhab:openhab
OPENHAB_CONF | /etc/openhab2 | openhab:openhab
OPENHAB_LOGDIR | /var/log/openhab2 | openhab:openhab
OPENHAB_BACKUPS | /var/lib/openhab2/backups | openhab:openhab
URLs: http://192.168.2.211:8080
https://192.168.2.211:8443
sihui@nucopenhab:~$ java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (Zulu 8.31.0.1-linux64) (build 1.8.0_181-b02)
OpenJDK 64-Bit Server VM (Zulu 8.31.0.1-linux64) (build 25.181-b02, mixed mode)It saves the Karaf Console history to the home directory (~/.karaf ) of the openhab user.
The same AccessDeniedException already occurred for users with 2.2.0-SNAPSHOT, see: Karaf "Failed to save history" WARN on ssh logout, how to change history file. So it might not be upgrade related.
Thx, yes, I found that post before I posted, but that user did use a manual openHAB install where there should be a /home/openhab directory.
So I need to create that directory manually?
As what user did you run openhab-cli console ? I usually run openHAB in Docker so I’m not familiar with the whole Debian packaging/setup. Perhaps @Benjy knows if this issue can also be solved without creating a home directory.
uid=1000(sihui) gid=1000(sihui) Gruppen=1000(sihui),4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),27(sudo),29(audio),30(dip),44(video),46(plugdev),112(netdev),116(lpadmin),118(scanner),122(sambashare)
I also tried sudo openhab-cli, same result, same error.
Thx 
Looks like you can also relocate the Karaf Console history file to another directory by adding an additional line to $OPENHAB_USERDATA/etc/system.properties :
karaf.history=/somedir/karaf.history
Thx, will try tomorrow.
I can’t reproduce this on a standard package. Out of interest, what does echo ~openhab give?
If the output is something other than /var/lib/openhab2, then somehow the openhab user was created outside the package config. You can fix with:
usermod -m -d /var/lib/openhab2 openhab
2 Likes
sihui@nucopenhab:~$ echo ~openhab
/home/openhab
After your fix:
sihui@nucopenhab:~$ echo ~openhab
/var/lib/openhab2
Strange thing is, I just migrated from a Pi to an Intel i3 with Lubuntu 18.04., so it was a clean install of openHAB2.
Thanks a lot, I will purge and reinstall in case there is some more going on in the background of my Lubuntu 
Edit: btw, no more errors after the fix when logging out from the openhab-cli console.
1 Like