Upgrade openHABa

Niedawno postanowiłem zrobić upgrade domowego openHABa z wersji 3.1.0 na 3.2.0. Moja instalacja działa na Raspberry Pi w kontenerze Dockerowym, a ponieważ jako katalogi z konfiguracją, pluginami i danymi mam montowane katalogi hosta, to zgodnie z oficjalną instrukcją aktualizacja powinna być banalna. Trzeba zatrzymać i usunąć kontener z aktualną wersją (wszystkie istotne dane zostają na hoście) a następnie ściągnąć i uruchomić nową. Dla porządku po usunięciu kontenera skasowałem logi z userdata/logs. Obraz wersji 3.2.0-debian ściągnął się bez problemów, zaczął uruchamiać i zawiesił się. Kontener co prawda był widoczny:

$ docker ps
CONTAINER ID   IMAGE                        ... CREATED         STATUS
e2906859d033   openhab/openhab:3.2.0-debian ... 2 minutes ago   Up 2 minutes (health: starting)

w logu userdata/update.log zapisało się:

...
Replacing userdata system files with newer versions...
Clearing cache...

Performing post-update tasks for version 3.2.0:

SUCCESS: openHAB updated from 3.1.0 to 3.2.0

ale już w logu userdata/logs/openhab.log było pusto, a po kilkunastu minutach Docker jednak uznał kontener za niezdrów:

$ docker ps
CONTAINER ID   IMAGE                        ... CREATED          STATUS
e2906859d033   openhab/openhab:3.2.0-debian ... 19 minutes ago   Up 19 minutes (unhealthy)

Komenda docker stop co prawda zadziałała, ale zapisała do syslogu mało zachęcające:

Container failed to exit within 10s of signal 15 - using the force

Przyznam się, że na tym etapie zatrzymałem się na dłuższą chwilę - nie mając nic w logach ciężko było znaleźć jakiś punkt zaczepienia. W końcu uruchomiłem kontener nie jako usługę, ale po prostu w terminalu za pomocą docker run ... dodatkowo usuwając z opcji --detach aby widzieć co dokładnie się dzieje. I stała się światłość - w ostanie linii logów, po wypisaniu której proces się zawieszał, było:

OpenJDK Client VM warning: No monotonic clock was available - timed services may be 
adversely affected if the time-of-day clock changes

na co Google od razu znalazł radę na forum openHABa i na Stack Overflow. Okazało się, że winna była zbyt stara biblioteka libseccomp2 zawarta w Debianie Buster (chodzi o hosta, nie kontener). Oczywistym rozwiązaniem byłby upgrade całego systemu do Bullseye, ale trochę obawiałem się tak radykalnej operacji, szczególnie że na oficjalnej stronie Raspberry Pi jest wprost napisane "we don’t support or recommend this". Dlatego zdecydowałem się na użycie repozytorium buster-backports, w którym jest już zaktualizowana wersja libseccomp2. Aby dodać repozytorium do systemu trzeba wykonać standardową procedurę:

$ sudo apt-key adv --keyserver keyserver.ubuntu.com \
 --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' \
 | sudo tee -a /etc/apt/sources.list.d/debian-backports.list

a następnie, po aktualizacji listy pakietów za pomocą:

$ sudo apt update

można zainstalować nową wersję biblioteki wskazując źródło pakietu za pomocą opcji -t:

$ sudo apt install libseccomp2 -t buster-backports

Po tej operacji ponowne uruchomienie kontenera openHAB kończy się spodziewanym:

[INFO ] [org.openhab.ui.internal.UIService   ] - Started UI on port 8080

Czekam z niecierpliwością na niespodzianki w zapowiadanej na 27. czerwca wersji 3.3.0 😅

P.S.

 

O co właściwie chodzi z owym monotonicznym zegarem? Okazuje się, że zarówno openHAB jak i Java są niewinne. W Debianie i wywodzących się z niego systemach, dla architektury arm32v7 (Raspberry Pi) kombinacja Dockera starszego niż 19.03.9 i biblioteki libseccom starszej niż 2.4.2 powoduje, iż w kontenerze nie jest dostępny poprawnie działający zegar. Wpływa to na cały system, w tym nawet komendę date (przykład ze zgłoszenia w projekcie Ubuntu):

$ docker run --rm -it --entrypoint /bin/bash ubuntu:20.04
root@8543aa82ff05:/# date
Thu Feb 26 08:20:11 UTC 1970

P.P.S.

Pierwszy wpis od 2756 dni. Z jednej strony fajnie, ale jednak trochę strasznie.