EDIT: Due to new knowledge that Maven is only contacted at first startup the topic is only valid for docker environments !!!
referring to the “outage” that happened from last thursday to friday that the Maven repository was unavailable causing the installation/activation of all bindings at startup of of OH instances running in a docker container as I learned that at the first startup OH is contacting the Maven repository. But for a docker container every startup is a “first startup”.
Hence I was wondering if a configuration flag is available or could be considered in the future to temporarily disable the requirement of accessing the repository during startup and start OH completely self-sufficiently?
Setting such a flag may have prevented a lot of long OH downtimes for all those who rebooted their docker container OH instances during this period.
Maybe I am on the wrong path with my idea but then there may be another way to prevent this from happening again
!!! This is not offense or criticism !!! Such things can happen and OpenHAB is the best home automation!!! It is just a well-intentioned idea to prevent such unwanted behaviour in the future.
Ok, so I understand that “normal” installations don’t have the problem and it looks that this is limited to docker environments as a docker container always starts “for the first time” when booted up …
So it maybe necessary for docker environments only?
EDIT:
I rephrased the topic title as I understand that this only affects first startups …
Bruce, I don’t understand your point. It seems that not only me but quite some OH users experienced that there environments did not start properly during thursday and friday because somehow the OH instance could not reach the Maven environment.
From what has been said above this contact only happens at the first startup which explains to me that docker environments are affected every reboot as the instance always comes up as “new” (if I understand docker right).
So, I assume that setting a flag in a docker environment could tell the container that it is not the first startup and hence all bindings should be installed.
I understand that OH instances always install the bindings during startup either driven by the addons.cfg or due to the configuration created through the UI. But what seems to be unique to docker environments is that they behave like it is always the first reboot - otherwise I can not understand why the problem occured in my container?
If installed with Linux packages I think there is an addons package that can be used for instances with no Internet access. At least that is the case with OH2.
I understand that OH instances always install the bindings during startup either driven by the addons.cfg or due to the configuration created through the UI. But what seems to be unique to docker environments is that they behave like it is always the first reboot - otherwise I can not understand why the problem occurred continuously in my container?
Interesting to hear that there is an addons package that can be used for NO internet access. But this would always disable the internet connection, right?
I would like to have the option that the default is the current normal behaviour to contact the repository as this is a good and valid feature. But for the unlikely case that the Maven repository is not available it should be possible to temporarily disable this connection during startup.
That would only occur of you do not have your volumes set up properly to keep the configuration & logging outside the container. Here is the recommendation ( from Docker Hub)
When you choose to install an add-on, openHAB will download it from the internet on request. If you plan on disconnecting your machine from the internet, then you will want to also install the add-ons package.
Hi Bruce,
thank you very much for your answer. My configuration is exactly like this having the three directories and the timezone and localtime file mounted from the outside. But even with that configuration I experienced thursday/friday this error:
indicating that my OH instance could not reach the Maven repository. But the internet connection from the container worked because accessing the internet via curl and wget was successful.
And I was not the only one having that problem. Please take a look in the community for several topics with similar problems. And the problem disappeared after the downtime of the community for me and for all others …
And it was confirmed that the problem was caused due to the missing connection to the repository … And when you tell me that the connection only occurs at the first startup then I am wondering why I had the error above evertime I rebooted my container which I have up and running since 4 weeks (and also my previous version 2.5.10 got this error because I kept the old container after the update 4 weeks ago and started it on thursday again to check if this version would work - but it also got this error).
This lead my to the conclusion that booting the container does the connection to Maven every time not only the first startup and hence I was thinking that disabling this connection attempt temporarily would solve this error.
I understood the problem was not about connection but about content I.e. missing repository files.
This would invoke a different error to a truly failed connection
Nevertheless, the circumvention is not to try it.
Isn’t this just a case of turning off OH add-ons “use remote repository”?
# Access Remote Add-on Repository
# Defines whether the remote openHAB add-on repository should be used for browsing and installing add-ons.
# This not only makes latest snapshots of add-ons available, it is also required for the installation of
# any legacy 1.x add-on. (default is true)
#
remote = true
I tried that and have set it to false (not only just comment it out as the default is true ) but it did not help.
If you are mounting user data into the container then it is not correct that the container is starting anew every time. Only if the container is upgraded to a different version or you’ve cleared the cache, or you have not mounted user data and create a new container does the OH go out and install new bindings.
So the question is, does any of the above apply in your case?
In answer to the original post, no, there is no way I know of to prevent maven from teaching out on startup if it needs to install some add-ons. Anything you do network wise outside of Docker is just going to be there same as the problem you experienced. OH won’t new able to reach maven and give you the same error.
So first I recommend considering if this is a problem worth fixing. In be all the years I’ve used ooenHAB this is the first time a pregnant like this has happened.
If so, consider creating a custom image with the add-ons installed like Bruce suggested. Then OH won’t reach out to install the add-ons and can install them from the local set.
Make sure to mount usersdata into the container. Refrain from manually clearing the cache. If changing to a new container fails, look in usersdata/backup. Every time the container changes versions, the entry point script creates a full backup of everything before clearing the cache so that the add-ons for the new version can be downloaded and installed. So if the upgrade fails, revert back to the old image, restore the backup, then start the container using the old version image. As long as the version in usersdata/etc/versions.properties matches the version of OH nthe image, usersdata is left unmodified and oh won’t try to install add-ons at startup.
I must admit that I have cleared the cache in the process of migrating from mysql persistence to jdbc persistence. In that context I have changed the appropriate .cfg files in the services directory and the .persist files in the persistence directory. And as I have experienced in the past that the .config files in the cache/org/openhab directory did not update when changing the files in /conf I have cleared the cache.
And this explains now for my case why my container had these troubles as clearing the cache made my OH instance believe that it has its first startup!!! Thank you for clarifying!!!
As other users raised very similar issues at the same time I was lead into the wrong direction.
Thank you for this background information. I will now be careful when clearing the cache … I started doing that as in some topics it is a given solution for some problems … but its obviously not the best
As I will now be careful with clearing the cache I do not expect to run into the same problem again in the future. Setting the userdata/etc/versions.properties manually is a circumvention that I can consider in case it becomes necessary.
So, with that knowledge my request for a flag seems not to be valid anymore. The other users can check for themselves if they are satisfied with your explanation.
