Settings from /etc/default/openhab2 are gone after upgrade to release 3.0

After upgrading openhab (release 2.5) running on a raspberry pi 4 to release 3.0 the settings in file /etc/default/openhab2 are no longer considered. The file location has moved to /etc/default/openhab.
During installation of openhab 3.0 these settings are not considered.
As consequence settings like EXTRA_JAVA_OPTS get lost and the system might no longer run stable.
It would be helpful if these settings could be considered during upgrade. If these is not intended, maybe it could be mentioned in the upgrade guide.

No. Strictly speaking this is a Java config not an OH config issue so an issue how you install your OS.
The “upgrade” to OH3 actually is a fresh install from scratch to exist in parallel to any eventually existing OH2 config, and you are expected to configure your OH3 from scratch, too.
Which means to start with a fresh /etc/default/openhab that you can change if you feel the need to.

Yes it is a Java config. But it is a config specific for openhab.
My remarks are related to the migration to openhab 3.0. In the documentation you can read:

From this description I expected that openhab2 specific configuration is considered by the upgrade.
But obviously the setting from /etc/default/openhab2 are not considered.

My recommendations is just to add a hint that this configuration might need to be added manually.

Such a hint might save other users a lot of time. The impact of the missing java setting have caused a couple of hard to analyze issues. E.g.: syntax check in vs code was not working, the semantic model took a long time to load.

Just like many other files on your system are.
I replied to explain why it isn’t in the docs and why IMHO it does not belong there.
Feel free to open a PR against the docs or the openhab-distro repo if you disagree with my POV (just please don’t expect things like this to happen by just posting it here, that isn’t how OH works).

BTW this only applies when you don’t use openHABian i.e. you explicitly chose to be responsible for setting up your OS yourself.

No in my opinion it is not like many other files in the OS. The file is named openhab2, it is related to openhab only and it gets invalid by the migration.

In case there are many other files which require similar attention after the upgrade please let me know these files.

Sorry, but I just tried to do as asked in the documentation where I read: “let us know if you experience anything strange”.

If you had welcome this input and asked me to create a PR request I would have been happy to help to improve the documentation to help other users of openhab. But unfortunately this is not the impression I got from your reply.

Furthermore I do not know whether there are other similar pit falls which should be mentioned along with /etc/default/openhab. In case I would make a PR I can only mention this specific pit fall.

By posting the same I hoped that this is taken as input to improve either the upgrade or the related documentation.

No. It remains to be valid for what it is, an OS Java (and more) config file for openHAB 2. It can co-exist with an OH3 install. The config file for OH3 is a different one, and OH3 does not care about OH2 config.
I understand you’re annoyed because if someone had told you that earlier you wouldn’t have had to dig around for hours and you want to save others from sharing your fate. I appreciate that.

That however does not mean your view on the state of things is correct let alone congruent with the OH maintainer’s and that your “fix” is a proper one and that the OH docs is the right place to put it.
BTW “docs” is a very large container-like description, you would need to get more specific.
That’s why I asked you to come up with a specific proposal (that’s what a pull request is, after all).
The docs maintainers would then review your proposal and if required they’ll tell you what to change about it (and eventually where there is a better place for it).
But you must not expect anyone to browse the forum to pick up proposals. We all have got more work ahead of ourselves than we can spend time for.
So this sort of posting is easily read as and considered a complaint or (unfair) critics.
I understand it isn’t in your case but please be aware that’s often a very thin line / small side step only.

If have put my proposal in a PR

Hi @BertramVielsack, I think you make a fair point, openHAB internal configuration was moved across, it would make sense that anything non-default which is also specific for openHAB should have moved across too, especially if those settings are likely to be the same between openHAB 2.x and 3.0 such as EXTRA_JAVA_OPTS. I can see how this behavior differs to expectation.

The /etc/default/openhab2 file also contains a lot of references to openHAB 2.x paths and may contain pre-existing changes that may break an openHAB 3.x setup. This is why it’s best being reset on this major upgrade, but you’re absolutely right, a warning of this should be mentioned in the docs.

I think /etc/default/openhab is the specific case here, being the only configuration file that the .DEB package installs that is not part of the standard openHAB distribution. Configuration from all other files that openHAB controls should be properly handled (at least a message will be displayed confirming a user choice).

That is not my expectation, I think ideally an openHAB 2->3 upgrade should require minimal manual efforts.

1 Like