Update auf openhab 4.3.3-1 hat alles zerschossen

[udo1toni]

Schau doch bitte mal in /var/log/openhab/openhab.log. Am besten stoppst Du openhab, entfernst die Datei und startest dann wieder, um den vollständigen Start zu Gesicht zu bekommen.

Code: Alles auswählen

sudo systemctl stop openhab.service
sudo rm /var/log/openhab/openhab.log
sudo systemctl start openhab.service

Falls die Datei anschließend nicht zu groß ist, kannst Du den Inhalt hier als Code markiert einstellen, aber vielleicht siehst Du auch direkt selbst einen Hinweis auf ein Problem...

[EiGudeWie]

Das ist eine gute Idee, aber leider nicht zielführend. Ich habe zwei openhab.log files am System:

Code: Alles auswählen

jens@odroidc2:/$ sudo find ./ -name openhab.log
./var/log/openhab/openhab.log
./var/log.hdd/openhab/openhab.log

Beide sind Größe 0 , also komplett leer.

[udo1toni]

Gut, dann versuche bitte mal:

Code: Alles auswählen

sudo systemctl stop openhab.service
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo systemctl start openhab.service

By the way: welche Ausgabe kommt bei

Code: Alles auswählen

systemctl status openhab.service

[EiGudeWie]

Hallo,

habe deine 4 Kommandos ausgeführt, die Logs bleiben nach wie vor trotzdem komplett leer.

zum Status:

Code: Alles auswählen

jens@odroidc2:~$ systemctl status openhab.service
● openhab.service - openHAB - empowering the smart home
     Loaded: loaded (/lib/systemd/system/openhab.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-03-08 16:31:14 CET; 6s ago
       Docs: https://www.openhab.org/docs/
             https://community.openhab.org
   Main PID: 9251 (java)
      Tasks: 32 (limit: 2018)
     Memory: 93.3M
        CPU: 15.028s
     CGroup: /system.slice/openhab.service
             └─9251 /usr/bin/java -XX:-UsePerfData -Dopenhab.home=/usr/share/openhab -Dop>

[udo1toni]

Schau bitte mal nach dem Inhalt von $OPENHAB_USERDATA/etc/log4j2.xml, die datei sollte etwa 5 kByte groß sein. Die Originaldatei auf github: https://github.com/openhab/openhab-dist ... log4j2.xml
Diese Datei steuert, was wie und wo geloggt wird. In der Datei org.ops4j.pax.logging.cfg im gleichen Verzeichnis ist ein Link auf die Datei eingetragen. Beide Dateien müssen existieren und im Zweifel auch den korrekten Inhalt haben, damit das Logging funktioniert.

[EiGudeWie]

Moin Moin,

OK, interessanter Hinweis. Also, ich mir mal meine .xml (lag in /var/lib/openhab/etc ) mit der offiziellen auf Github verlinkten .xml Datei vergliechen.

Ergebnis:
Der Code, also der Inhalt ist absolut identisch.

Fazit:
Laut der .xml wird das LOG hier hin geschrieben: fileName="${sys:openhab.logdir}/openhab.log

Ich habe 2 openhab.log Dateien im System:

Code: Alles auswählen

/var/log/openhab/openhab.log
/var/log.hdd/openhab/openhab.log

Beide sind leer ;-(

Und Openhab hat definitiv Rechte dahin zu schreiben:

Code: Alles auswählen

jens@odroidc2:/var/log/openhab$ ls -lah
insgesamt 8,0K
drwxr-xr-x  2 openhab openhab 4,0K  8. Mär 12:44 .
drwxr-xr-x 14 root    root    4,0K  8. Mär 16:35 ..
-rw-r--r--  1 openhab openhab    0  9. Mär 10:45 audit.log
-rw-r--r--  1 openhab openhab    0  9. Mär 10:45 events.log
-rw-r--r--  1 openhab openhab    0  9. Mär 10:45 openhab.log
-rwxr-xr-x  1 openhab openhab    0  9. Mär 00:00 Readme.txt

Es ist sehr merkwürdig...

[udo1toni]

Wo auch immer /var/log.hdd/ herkommt, das dürfte etwas mit Deinem System zu tun haben, openHAB selbst legt eine solche Datei nicht an.
Da Deine Grundlage ja ein Odroid mit einem Armbian ist, wäre meine Vermutung dazu, dass Du (im Hintergrund?) ein Programm laufen hast, welches evtl. die Schreibzugriffe in einer RAM Disk umleitet.
/var/log.hdd/ wäre dann der Mount für das "echte" Dateisystem, damit die Daten beim Herunterfahren dennoch gesichert werden können.
Das ist aber nur meine Vermutung.

Das Update von OH3 auf OH4 ist eigentlich wirklich einfach, innerhalb der OH4-Familie sollte es überhaupt keine Probleme geben, schon gar nicht so, dass das System nicht mehr sauber hoch fährt. Spätestens nach reset-ownership und clean-cache muss das System ganz normal starten (dauert dann natürlich etwas länger als normal, weil openHAB die Bindings neu runterladen muss, aber nach ein paar Minuten muss die Oberfläche erreichbar sein und auf jeden Fall muss in openhab.log etwas landen.

Du könntest noch versuchen, ob Du auf die Karaf Konsole kommst - bei laufendem openHAB openhab-cli console (das Passwort lautet gewöhnlich habopen). Aber ich gehe nicht davon aus, dass die Konsole erreichbar ist, wenn schon das Logging nicht funktioniert.

[EiGudeWie]

Hallo,

Vorsicht nochmals, ich bin ja garnicht wie erst von mir falsch angegeben auf OH3 sondern schon im 4er Bereich.

Code: Alles auswählen

openHAB 4.3.2
Release Build
Main UI Commit 6dc07385 

D.h. ich will ein Update von 4.3.2 auf 4.3.3 durchführen, was ja eigentlich ein No Brainer sein dürfte...

Wenn ich in die Console will kommt folgende Meldung:

Code: Alles auswählen

jens@odroidc2:~$ openhab-cli console

SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J(W): Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
SLF4J(W): Ignoring binding found at [jar:file:/usr/share/openhab/runtime/system/org/apache/karaf/org.apache.karaf.client/4.4.6/org.apache.karaf.client-4.4.6.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J(W): See https://www.slf4j.org/codes.html#ignoredBindings for an explanation.
Logging in as openhab
Failed to get the session.

Ich denke in meiner OH Instanz ist etwas ganz grundlegendes falsch. In der alten funktionalen Version hat nämlich auch das Loggen funktioniert...

[EiGudeWie]

Habe jetzt meinen Dump der SD Karte zurückgesepielt und siehe da, OpenHAB läuft wieder. Auch die Logs tun...
Interessanterweise ist dort sogar ein Java Fehler, aber es funzt trotzdem alles (soweit ich sehen kann)

Code: Alles auswählen

2025-03-09 19:30:10.107 [INFO ] [org.openhab.core.Activator          ] - Starting openHAB 4.3.2 (Release Build)
2025-03-09 19:30:12.131 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Berlin'.
2025-03-09 19:30:12.186 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Location set to '50.45244062850645,7.796612977981568'.
2025-03-09 19:30:12.193 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'de_DE'.
2025-03-09 19:30:12.206 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'SI'.
2025-03-09 19:30:46.615 [INFO ] [.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2025-03-09 19:30:48.123 [WARN ] [le.handler.ItemStateConditionHandler] - Item 'OneCallAPILokalesWetterundWettervorhersage_Current_Temperature' needed for rule '65990f519d' is missing. Condition '3' will not work.
2025-03-09 19:30:48.150 [WARN ] [le.handler.ItemStateConditionHandler] - Item 'OneCallAPILokalesWetterundWettervorhersage_ForecastHours02_Temperature' needed for rule '65990f519d' is missing. Condition '5' will not work.
2025-03-09 19:30:48.160 [WARN ] [dule.handler.ItemStateTriggerHandler] - Item 'OneCallAPILokalesWetterundWettervorhersage_Current_Temperature' needed for rule '65990f519d' is missing. Trigger '1' will not work.
2025-03-09 19:30:59.981 [WARN ] [.discovery.sddp.SddpDiscoveryService] - listenActiveScanUnicast() error 'Operation not permitted'
2025-03-09 19:31:14.523 [WARN ] [.io.rest.auth.internal.TokenResource] - Couldn't find a user with a session matching the provided refresh_token
2025-03-09 19:31:14.532 [WARN ] [.io.rest.auth.internal.TokenResource] - Token issuing failed: invalid_grant
2025-03-09 19:31:14.584 [INFO ] [ab.ui.habpanel.internal.HABPanelTile] - Started HABPanel at /habpanel
2025-03-09 19:31:14.673 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.0.63:8080/rest/auth/logout's Observer
2025-03-09 19:31:14.771 [WARN ] [.transport.servlet.ServletController] - Can't find the request for http://192.168.0.63:8080/rest/'s Observer
2025-03-09 19:31:18.282 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2025-03-09 19:31:18.506 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: Cannot invoke "jdk.internal.platform.CgroupInfo.getMountPoint()" because "anyController" is null
        at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getInstance(CgroupV2Subsystem.java:80) ~[?:?]
        at jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:114) ~[?:?]
        at jdk.internal.platform.CgroupMetrics.getInstance(CgroupMetrics.java:177) ~[?:?]
        at jdk.internal.platform.SystemMetrics.instance(SystemMetrics.java:29) ~[?:?]
        at jdk.internal.platform.Metrics.systemMetrics(Metrics.java:58) ~[?:?]
        at jdk.internal.platform.Container.metrics(Container.java:43) ~[?:?]
        at com.sun.management.internal.OperatingSystemImpl.<init>(OperatingSystemImpl.java:182) ~[?:?]
        at com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(PlatformMBeanProviderImpl.java:280) ~[?:?]
        at com.sun.management.internal.PlatformMBeanProviderImpl$3.nameToMBeanMap(PlatformMBeanProviderImpl.java:199) ~[?:?]
        at sun.management.spi.PlatformMBeanProvider$PlatformComponent.getMBeans(PlatformMBeanProvider.java:195) ~[?:?]
        at java.lang.management.ManagementFactory.getPlatformMXBean(ManagementFactory.java:687) ~[?:?]
        at java.lang.management.ManagementFactory.getOperatingSystemMXBean(ManagementFactory.java:389) ~[?:?]
        at io.micrometer.core.instrument.binder.system.ProcessorMetrics.<init>(ProcessorMetrics.java:79) ~[?:?]
        at org.openhab.core.io.monitor.internal.metrics.JVMMetric.bindTo(JVMMetric.java:59) ~[?:?]
        at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.lambda$0(DefaultMetricsRegistration.java:96) ~[?:?]
        at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
        at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.registerMeters(DefaultMetricsRegistration.java:96) ~[?:?]
        at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.onReadyMarkerAdded(DefaultMetricsRegistration.java:105) ~[?:?]
        at org.openhab.core.internal.service.ReadyServiceImpl.lambda$0(ReadyServiceImpl.java:51) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) ~[?:?]
        at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[?:?]
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) ~[?:?]
        at java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1850) ~[?:?]
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?]
        at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?]
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
        at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) ~[?:?]

Naja, d.h. dann wohl ich muss auf OH 4.3 bleiben... mehr geht nicht. Habe dementsprechend OpenHab in der Sources.List auskommentiert.

[udo1toni]

Ich denke eher, Du musst anders an das Problem heran gehen.

Ziehe ein komplettes Backup von openHAB (openhab-cli backup --full - eventuell auch mit nur einem Minuszeichen... bin gerade zu faul zum verifizieren...)
Setze das System komplett neu auf (logischerweise am besten auf einer anderen Speicherkarte).
Installiere auf dem "jungfräulichen" System Java 17 und das aktuelle stable openHAB (das wäre 4.3.3) ohne das Backup einzuspielen.
Läuft openHAB?
Super, dann stoppe openHAB und spiele das Backup ein.
openHAB sollte danach immer noch problemlos laufen.
Ist das nicht der Fall, müsstest Du statt des vollständigen Restore leider die wichtigsten Dateien manuell umkopieren (/etc/openhab/*, /var/lib/openhab/jsondb/*, einige Dateien aus dem dazu parallel liegenden Verzeichnis ./etc/ (das betrifft vor allem die Konfiguration von Persistence, logging und automatisch generierte Schlüssel für Webservices), dann ist in irgendeiner der tiefer im System versteckten Dateien der Wurm drin.
Läuft hingegen bei einem komplett neu aufgesetzten System openhAB ebenfalls nicht, wäre das einen Issue im englischen Forum wert, denn grundsätzlich ist openHAB komplett hardwareunabhängig, das ist ja der Witz an der Java-Lösung. Erst mit der nächsten Version wird als Bedingung 64 Bit gesetzt sein, selbst das sollte auf dem Odroid C-2 ohne Probleme gehen. Momentan ist lediglich das zur Verfügung stehende RAM wichtig - und natürlich muss eine Java 17 Engine vorhanden sein.