Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up addons folder on upgrade #1574

Open
rkoshak opened this issue Aug 18, 2023 · 15 comments
Open

Clean up addons folder on upgrade #1574

rkoshak opened this issue Aug 18, 2023 · 15 comments

Comments

@rkoshak
Copy link
Contributor

rkoshak commented Aug 18, 2023

Leaving old .kar and .jar files in the addons folder after an upgrade can lead to significant problems (see https://community.openhab.org/t/endless-loop-during-start-of-oh4-0-2-service-after-upgrade-from-oh4-0-1/148774). I recommend that the installation scripts should look for and at a minimum move those files somewhere else as part of an upgrade, with logs of course.

It gets tricky with snapshots I think because moving from one snapshot to the next within the same overall version of OH doesn't necessarily invalidate the stuff in the addons folder. But I think having OH come up in an infinite loop because the files are there is event worse.

@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/openhab-4-migration-faq/148144/37

@mstormi
Copy link
Contributor

mstormi commented Aug 18, 2023

how is it supposed to work on upgrade - remove all ? Or is there a means to distinguish 'good' from 'bad' ones addons?

@holgerfriedrich
Copy link
Member

I think minor updates and snapshots should be excluded from the proposed feature.
I would not expect losing all custom compiled add-ons after a patch level upgrade of the OH via apt upgrade.
Just my two cents.

@rkoshak
Copy link
Contributor Author

rkoshak commented Aug 18, 2023

how is it supposed to work on upgrade - remove all ?

I would expect them all to be removed on a release upgread (e.g. 4.0 to 4.1). Testing or Snapshot releases I can imagine multiple ways, including doing nothing.

I could even see it being smart and only removing those it "knows" somehow are incompatible but to do something like that I think it would have to be implemented in the upgrade tool.

But I think it's pretty reasonable to remove them (and by remove I mean move or even just rename so thst OH doesn't try to load them) when upgrading between release versions. In those cases the add-ons have a high likelihood of not working.

@mstormi
Copy link
Contributor

mstormi commented Aug 18, 2023

you want this to be done by the postinstall script ? ping @BClark09

@Flole998
Copy link
Member

I have a few self-built addons and if they would be deleted I would be pretty mad cause I would have to rebuild them or see where I have an original copy of those. I suggest doing at maximum a warning, no movement or deletion.

@rkoshak
Copy link
Contributor Author

rkoshak commented Aug 25, 2023

More upset than when OH won't come up or goes into an infinite loop because those add-ons are no longer compatible with OH causing it to crash (which has actually happened and why I files this issue)?

And again, not deleting, either renaming (so OH doesn't try to load them) or moving the files to a well known location. You won't lose anything.

@Flole998
Copy link
Member

I've never had such an issue, only some of the add-ons refusing to load due to missing dependencies.

@rkoshak
Copy link
Contributor Author

rkoshak commented Sep 30, 2023

Here's another case of this problem happening.

https://community.openhab.org/t/bindings-wont-install-after-migrating-from-oh3-to-oh4/150016

@rkoshak
Copy link
Contributor Author

rkoshak commented Jul 8, 2024

With OH 4.2 release here's another case, this time with a relatively experienced user.

https://community.openhab.org/t/solved-cant-get-any-page-from-basicui-with-4-2-release/157077

At least now it doesn't seem to crash all of OH at least. But it still would be nice to at least get some logs from the upgrade scripts when it sees files in the add-ons folders. If there are not objectiosn I can submit a PR that does that much if the idea of modifying or moving the add-on files themselves remains objectionable.

@openhab-bot
Copy link
Collaborator

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/solved-cant-get-any-page-from-basicui-with-4-2-release/157077/10

@florian-h05
Copy link
Contributor

I would agree on having a warning logged for each JAR/KAR inside the add-on folder during the upgrade in the postinstall script, probably before the upgrade tool runs.

@rkoshak
Copy link
Contributor Author

rkoshak commented Jul 8, 2024

Possibly related: openhab/openhab-core#4302

@J-N-K
Copy link
Member

J-N-K commented Jul 17, 2024

IMO whoever puts add-ons in the addons folder is responsible for ensuring that they are compatible. With the two marketplaces (community and JSON) as well as the distribution add-ons there are three supported ways of installing add-ons that ensure compatibility.

Dropping add-ons in the folder is a little bit line textual configuration: you should now what you are doing. If not, stay away from it and let the magic work.

@rkoshak
Copy link
Contributor Author

rkoshak commented Jul 17, 2024

I would tend to agree except for the fact that it becomes a lot of work helping users who experience problems because of bad jar files in the addons folder. The hardest part is even knowing the files are there. because those who have OH crash or experience OOM problems and the like never think to tell us right away that they have files in addons in the first place. At least with some warnings we can know that right away or ask whether there are warnings in the upgrade log.

In short, it's not a problem for me when upgrading with a jar file in the add-ons folder as I never have jar files there. But it is a problem for mehelping others on the forum which is why I opened the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants