Preparing the openHAB 2.2 release


(Victor) #81

Apparently. I get

Critical /proc/self/exe readlink failure.

response when asking java -version


(Ben Clark) #82

That doesn’t look good. :thinking:

Are you able to reinstall it through the config menu or via apt?


(Victor) #83

In progress via apt.

upd: succeed! Now version shows:

openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)

(Victor) #84

Now looks worse

ec 18 15:49:27 orangepione systemd[1]: Started openHAB 2 - empowering the smart home.
Dec 18 15:49:28 orangepione karaf[19322]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione karaf[19322]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione systemd[1]: openhab2.service: Main process exited, code=exited, status=1/FAI
Dec 18 15:49:28 orangepione karaf[19411]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione karaf[19411]: /usr/share/openhab2/runtime/bin/karaf: 199: [: Illegal number:
Dec 18 15:49:28 orangepione systemd[1]: openhab2.service: Control process exited, code=exited status=1
Dec 18 15:49:29 orangepione systemd[1]: openhab2.service: Unit entered failed state.
Dec 18 15:49:29 orangepione systemd[1]: openhab2.service: Failed with result 'exit-code'.
Dec 18 15:49:31 orangepione systemd[1]: Stopped openHAB 2 - empowering the smart home.
Dec 18 16:40:29 orangepione systemd[1]: Started openHAB 2 - empowering the smart home.
Dec 18 16:40:32 orangepione karaf[22840]: Unable to update instance pid: Unable to create directory /var
Dec 18 16:40:37 orangepione karaf[22840]: java.lang.RuntimeException: Exception instantiating lock class
Dec 18 16:40:37 orangepione karaf[22840]: Karaf can't startup, make sure the log file can be accessed an
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.Main.createLock(Main.java:490
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.Main.doMonitor(Main.java:388)
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.Main.access$300(Main.java:75)
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.Main$3.run(Main.java:379)
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.lang.reflect.InvocationTargetException
Dec 18 16:40:37 orangepione karaf[22840]:         at sun.reflect.NativeConstructorAccessorImpl.newInstan
Dec 18 16:40:37 orangepione karaf[22840]:         at sun.reflect.NativeConstructorAccessorImpl.newInstan
Dec 18 16:40:37 orangepione karaf[22840]:         at sun.reflect.DelegatingConstructorAccessorImpl.newIn
Dec 18 16:40:37 orangepione karaf[22840]:         at java.lang.reflect.Constructor.newInstance(Construct
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.Main.createLock(Main.java:486
Dec 18 16:40:37 orangepione karaf[22840]:         ... 3 more
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.lang.RuntimeException: Karaf can't startup, ma
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.lock.SimpleFileLock.<init>(Si
Dec 18 16:40:37 orangepione karaf[22840]:         ... 8 more
Dec 18 16:40:37 orangepione karaf[22840]: Caused by: java.io.FileNotFoundException: /var/lib/openhab2/tm
Dec 18 16:40:37 orangepione karaf[22840]:         at java.io.RandomAccessFile.open0(Native Method)
Dec 18 16:40:37 orangepione karaf[22840]:         at java.io.RandomAccessFile.open(RandomAccessFile.java
Dec 18 16:40:37 orangepione karaf[22840]:         at java.io.RandomAccessFile.<init>(RandomAccessFile.ja
Dec 18 16:40:37 orangepione karaf[22840]:         at org.apache.karaf.main.lock.SimpleFileLock.<init>(Si
Dec 18 16:40:37 orangepione karaf[22840]:         ... 8 more


(Ben Clark) #85

Actually that’s getting further along now. Not sure how it’s got like this, but I’d check the state of the SD card.

Check who owns the folders /var/lib/openhab2with ls - l and if it’s not openhab or openhabian, make sure to set it so with chown - R. Otherwise I’d suggest making a new thread on this forum so we can continue the discussion without going too off topic here.

There’s an option for fixing permissions in openhabian-config.


(Sascha ) #86

Hey,

I just did the upgrade and mostly worked fine. The first start of 2.2 resulted in a rather unstable environment and more than 23000 threads hogging on memory. I rebooted and now I am stable for over an hour with ~300 threads and memory doing fine.

Perhaps your SD card really gave up on this. Does dmesg show any hints?


(Victor) #87

SD card seems to be ok. Now OH 2.2 is running.
What I did is removed zulu, installed oracle java, fixed permissions.

Observe higher RAM (~75%) and almost no CPU load (~5%), which is cool!
Thank you ALL!


(Simon Merschjohann) #88

I resolved my issue regarding rule engine installation. There was an error in my custom docker image, it should be fine everywhere else


(Andreas Kielkopf) #89

Thank you for your tip!
I have manjaro(arch) and there was only a Package for 2.1.0. This worked fine.

I tried to update wit the sudo ./runtime/bin/update 2.2.0 but was stuck by an error on starting openhab stating Karaf can’t startup, make sure the …

When i found your post, i did:

cd /var/lib/openhab2
chown openhab:openhab -cR *

now openhab works again.:grinning::sunglasses:

it seems the update-scrip of openhab works as root:root and did not change the updated files to openhab:openhab
Andreas


(Tomasz Maruszak) #90

Hey All,

I am not sure where to ask this, but this topic seems relevant to 2.2.0 release.

I will want to make a PR to fix 2758 for openhab2-addons 2.2.0 (YamahaReceiver). In my opinion this should be released as a patch version 2.2.1 to openhab2-addons, so that users get this faster than having to wait for 2.3.0 (or having to use the unstable 2.3.0-snapshot version).

More discussion about the issue here. It is not a blocker for users, but surely is annoying.

My changes are made on top of the 2.2.0 tag. Is there an established process to push hotfixes to releases and also a way for users to get the updates automatically?

If not, then I could push the PR to the 2.3.0-snapshot.

Please let me know how to go about this.


(Patrick Fink) #91

The issue is that we currently have no process to easily create hotfix branches and create releases on top of them. Doing research and making PoCs regarding this is the next thing on my ToDo list. Maybe we have something until end of the week, but to be honest I cannot promise anything, I’ll just do my best. If somebody wants to support in the area of config and release management, do not hesitate to ping me.

Cheers,
Patrick


(Tomasz Maruszak) #92

Thanks for confirming the current situation and explaining the future plans. This is exactly what I needed. Given there is no actual process in place yet, I will use the usual route of making my PR on top of latest master (2.3.0-snapshot).

@pfink where could I check to see the progress on establishing the patch process? Is there a working community thread or an github isse I could subscribe to? I could not find anything in this topic.

Thanks
Tomasz


(Patrick Fink) #93

For specific sub-tasks, there is normally a GitHub issue if it can be related to a particular repository. As it’s a more cross-cutting concern topic, most of the discussions happened in the openhab-distro Gitter chat so far: https://gitter.im/openhab/openhab-distro


(Patrick Fink) #94

Hi all,

stable branches are created now! Maybe the question against which branch a hotfix should go could be answered by @maintainers? To avoid cherry picking, stable branch would be better, probably?


(Kai Kreuzer) #95

Any fix should always first be done on master. If it is decided (contributor together with the repo maintainer(s)) that it should go into a release branch, the simplest solution would be a cherry-pick by the maintainer. If it is a bigger change (which should be an exception for a patch) and there are conflicts, then it makes sense to ask the contributor to create a dedicated PR against the release branch.


(Patrick Fink) #96

Hi all,
our Jenkins release pipeline supports now building releases on top of branches as well. So technically, we’re able to do stable releases without big efforts now :slight_smile:


(Ganesh) #97

I think the release should not be a “tag” in git, it should be a branch. Like 2.1.0-bugfix, 2.2.0-bugfix. All people may not be able to keep running on their toes with 2.3.0-SNAPSHOT or 2.4.0-SNAPSHOT.


(Ganesh) #98

I would suggest a “LTS” long term support release concept just like Ubuntu folks. OH 2.1.0 stable was released in Jan 2017, maintained for 6 months until july 2017, nobody talks about 2.10-STABLE now. There is 2.2.0-STABLE, and the people are pushing all fixes to 2.3.0-SNAPSHOT. And there is no binary nor source compatibility among 2.10, 2.2.0 and so it will be with 2.3.0-STABLE. So basically the community asks everybody (binding devs and consumers) to keep running on their toes with “master” branch.
If you release something, you need to stand behind it at least for two years, as a community or company whichever is the case.


(Kai Kreuzer) #99

Hi Ganesh,

Yes, this would be awesome, thanks for volunteering!
As a matter of fact, the branches already exist (see e.g. https://github.com/openhab/openhab2-addons/commits/2.2.x), it is just that no PRs with fixes have been created for it by anyone yet. It would be great if you could help identify critical issues/bugfixes that should be ported to those branches and create the according PRs. We will make sure to merge timely merge them and create regular 2.2.x patch release builds!

Cheers,
Kai


(Ganesh) #100

Kai, that is what I was hoping. I am always on board supporting LTS releases or stable releases. Off topic, there were some slowdowns in 2.2 because of log4j rolling random access appender, the issue shows after 24 hours of activity, something related to locking in that appender. We are investigating the issue. We reverted back to RollingFile appender. There might be (and there are) many such important issues on top of stable releases (2.1.0, 2.2.0), thats why we need a branch instead of tag to maintain the release.