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.
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.
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=300
Hmm, 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.
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 .
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/.
Thanks for helping out with testing everyone!
Karaf 4.2.1 is now available in the latest 2.4.0-SNAPSHOT (build #1362).
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
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.