Closed mstormi closed 4 years ago
openhab2-addons
and openhab2-addons-legacy
have a dependency on openhab2
.
My understanding of apt, was that it would pre-inst
each package before calling the post-inst
scripts, openHAB is shutdown during the before installation and only started again after installation:
ben@debian:~$ sudo nano /etc/apt/sources.list.d/openhab2.list
ben@debian:~$ sudo apt update && sudo apt upgrade
[...]
The following packages will be upgraded:
openhab2 openhab2-addons
2 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 286 MB of archives.
After this operation, 70.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Fetched 286 MB in 3min 17s (1,453 kB/s)
Reading changelogs... Done
(Reading database ... 265301 files and directories currently installed.)
Preparing to unpack .../openhab2_2.4.0~20181121003414-1_all.deb ...
Unpacking openhab2 (2.4.0~20181121003414-1) over (2.3.0-1) ...
Preparing to unpack .../openhab2-addons_2.4.0~20181121003414-1_all.deb ...
Unpacking openhab2-addons (2.4.0~20181121003414-1) over (2.3.0-1) ...
Setting up openhab2 (2.4.0~20181121003414-1) ...
Installing new version of config file /var/lib/openhab2/etc/scripts/shell.completion.script ...
Installing new version of config file /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg ...
Listing important changes for version 2.4.0:
[...]
### openHAB was not running so will not start automatically...
### In order to start openhab2, execute
sudo /bin/systemctl start openhab2.service
Setting up openhab2-addons (2.4.0~20181121003414-1) ...
Processing triggers for systemd (239-12) ...
The ordering of this tells me that the files are unpacked before openHAB is assessed to restart. If I have misunderstood something here, are you seeing something different here?
Hmm, dunno if I have seen something different but there's a problem with this: openHAB is still running while apt overwrites addons .jars and .kars so openHAB/Karaf will recognize there's newer ones and will initiate (re)loading the corresponding bindings before it gets shutdown. That'll create an unnecessary delay and eventually further problems (not sure what happens if it's shutdown while Karaf internally copies the binding jar on to its final destination ?) but then again I think my initial 're-ordering' idea wouldn't help here. Can you think of the post-inst scripts take care of this ?
openHAB is stopped pre-inst on the openhab2 package. So it won't be up during unpacking.
The only way I can see the addons being updated while openHAB is still running is if openhab2-addons is updated individually (without openhab2) : see issue #116
openHAB is stopped pre-inst on the openhab2 package. So it won't be up during unpacking.
Could you double-check please ? If that's true I'm fine with closing this issue (although I'll still wonder why I have seen this happen, then).
Hi @mstormi, reviewing old issues here. I've tried to find a way of getting openHAB to stay online while it is being updated, but I've had no luck getting the issues you were experiencing. #116 will still be an open issue though which I think needs to be fixed.
When I apt-get (dist-)upgrade on my openHABian (or any debian), it'll offer me the packages to upgrade in a particular order, openhab2 being first and openhab2-addons(-legacy) after. Now that resulted in openhab2 being (re)started without that the next package was installed (apt-get was still busy downloading that). So that results in the updated OH2 version running against old addons, and a "restart" of that addons part of the code whenever the remaining packages installed successfully. Not sure about the full impact but one for sure thing is that it'll delay startup (and given the large number of users to run on RPi that's not to be underestimated as a problem/improvement).
Shouldn't we sort of rework-reorder-whatever this to force addons to get installed BEFORE main OH2? Not sure if we can simply change the order of packages the repo offers, or how to accomplish that at all.