Kein Zugriff mehr auf Openhabian

[Ede24]

Guten Morgen,

bei mir läuft openHAB 4.1.2 auf einem Raspberry Pi 3b. Bis gestern Abend lief alles problemlos.
Gestern habe ich mich wie gewohnt über Putty auf dem Raspberry Pi angemeldet und anschließend ein Backup gemacht.
Um die Persitence auf die SD karte zu schreiben habe ich den Raspberry Pi anschließend mit dem Befehl sudo reboot neugestartet.

Danach ist mir als erstes aufgefallen, dass die Persitence seit dem letzten Neustart (14.04.24) nicht mehr vorhanden war. Das ist zwar schade aber in meinem Fall verschmerzbar.

Nun zum eigentlichen Problem. Seit dem Neustart kann ich nicht mehr über Putty auf den Pi zugreifen. Das Fenster öffnet sich zwar kurz schließt sich aber direkt wieder, ohne Fehlermeldung.
Der Zugriff auf die openhab Benutzeroberfläche funktioniert problemlos: http://openhabian:8080/
Jedoch habe ich dort von einem neuen Gerät aus keinen Zugriff auf die Einstellungen (Admin-Zugriff), da meine Openhab Zugangsdaten nicht akzeptiert werden. Es kommt nur "Bitte erneut versuchen" als Antwort.
Auf Geräten auf denen ich schon angemeldet bin, funktioniert der Admin-Zugriff.

Um der Sache auf den Grund zu gehen habe ich den Pi jetzt an eine Bildschirm angeschlossen und versucht mich anzumelden.
Leider scheitert jeder Anmeldungsversuch mit der Fehlermeldung: /bin/bash: 1 Syntax error: Unterminated quoted string

Gebe ich ein falsches Passwort ein kommt nur: Login incorrect.

Scheinbar besteht irgendein Problem mit den Berechtigungen. Weder die openhabian Zugangsdaten noch die openhab Admin Zugangsdaten werden akzeptiert.

Diverse Neustarts haben nichts geholfen.
Interessanterweise bleiben die Persistence Daten trotz unsauberen Neustart (Stromquelle trennen, da Neustart über Kommandozeile nicht möglich) erhalten.

Wie kann ich den diese Fehler beheben; bzw. wie kann ich mich wieder einloggen?

Vielen Dank und Viele Grüße Edmont

[udo1toni]

Die Frage ist, was da überhaupt schief geht.
Evtl. ist eine der Umgebungsvariablen schuld.

Die einfachste Möglichkeit, auf das Dateisystem zugreifen zu können, ist, ein anderes GNU/Linux zu starten und anschließend per chroot in die openHABian Umgebung zu wechseln. Leider ist das aber nicht so einfach, wie der Satz klingt
Du brauchst dazu:

1. Ein System, auf dem GNU/Linux läuft in das Du Dich einloggen kannst
2. Die Möglichkeit, die SD-Karte in das laufende System aus 1. einzubinden

Du kannst z.B. ein Standard Raspberry Pi OS auf einer anderen SD-Karte aufspielen und dieses als Basissystem verwenden. Du brauchst dann nur einen zusätzlichen SD-Kartenleser, um auf die Micro-SD-Karte zuzugreifen, auf der openHAB eingerichtet ist.
Alternativ bietet es sich an, auf dem Desktop PC (vermutlich Windows) eine VM zu erstellen (z.B. VMware Player), in dieser VM Debian zu installieren und anschließend die Micro-SD-Karte am PC in die VM hineinzureichen. Ich setze voraus, dass Du einen PC hast, der Virtualisierung beherrscht und ein Micro-SD-Karten Lesegerät eingebaut hat - das ist heutzutage quasi bei allen Geräten der Fall... So kannst Du ohne zusätzliche Kosten auskommen (keine zusätzliche Micro-SD-Karte, kein extra Lesegerät).

Mit dem Befehl chroot kann man die Wurzel des Dateisystems virtuell verschieben. Man loggt sich z.B. als root ein, mountet die Micro-SD-Karte von openHAB unter /mnt/ und führt chroot /mnt/ aus. Ab sofort wird alles, was auf / zeigt, in Wirklichkeit in /mnt/ erledigt. Da man bereits root ist, kann man nun einfach alle Dateien manipulieren. Man könnte z.B. mit passwd openhabian das Passwort für den User openhabian setzen, und zwar im Dateisystem, welches in /mnt/ gemountet ist.
Nur deutet die Fehlermeldung darauf hin, dass nicht das Passwort das Problem ist...
Mein erster Tipp wären die Umgebungsvariablen, die werden allgemein mittels verschiedener Dateien home-Verzeichnis des Users definiert. Prüfe aus der chroot-Umgebung heraus, was der Befehl export als Ausgabe liefert. Achte insbesondere auf Zeilen, die Anführungszeichen enthalten. Ein heißer Kandidat ist hier die PATH-Variable.
Sollte export keine Auffälligkeiten ergeben, könnte es sein, dass export nicht die Umgebungsvariablen aus der chroot Umgebung verwendet (ist etwas her, dass ich das Tool selbst brauchte...)
Im Zweifel musst Du die verschiedenen Dateien abklappern, in denen die Umgebungsvariablen gesetzt werden, das müssten für alle User zusammen erst mal die Datei /etc/profile sein. Außerdem gibt es noch das Verzeichnis /etc/profile.d/, alle Dateien in diesem Verzeichnis werden ebenfalls für alle User geladen.
Wie gesagt, PATH ist ein heißer Kandidat. Sieht dort alles ok aus, so musst Du noch tiefer graben und Dir die Dateien des Users anschauen.
Im Pfad /home/openhabian/ sind das die Dateien .bash_profile, .bash_login und .profile (in dieser Reihenfolge werden die Dateien geladen).
Wenn Du eine Zeile findest, in der irgendwie ein Anführungszeichen zu viel gelandet ist, korrigierst Du die entsprechende Zeile und drückst die Daumen, dass dies der gesuchte Fehler war.
Anschließend verlässt Du die chroot Umgebung mittels exit. Danach wirfst Du die SD-KArte aus (unmount /mnt/), baust sie wieder in den Pi ein und startest ganz normal.

[Ede24]

Wow, erstmal danke für die ausführliche Antwort.
Leider bin was Linux angeht, ein absoluter Anfänger.
Ich werde am Wochenende Mal versuchen mich an deiner ausführlichen Beschreibung entlang zu hangeln.
Windows PC und SD Karten Leser sind vorhanden.

Alternativ spiele ich schon länger mit dem Gedanken mein System Mal neu aufzusetzen. Ich habe Anfang 2022 begonnen mit openhabian zu experimentieren und bin seit dem mit der ersten Installation unterwegs. Glücklicherweise habe ich auch gestern noch ein Backup mit der openhabian-config gemacht.
Wie aufwändig ist so eine Neuinstallation bei gleichzeitigem Umzug auf einen Raspberry Pi 4?
Reicht es da openhabian neu zu installieren und das Backup einzuspielen oder ist das mit mehr Aufwand verbunden.
Mein System ist ziemlich einfach mit etwas Mqtt, Modbus RTU & TCP und http Abfragen.

Viele Grüße Edmont

[udo1toni]

Da Du ja schon openHAB 4.1.2 nutzt und das Backup hast, sollte eine Neuinstallation ein Kinderspiel sein.
Schritt 1: Du erzeugst mit dem Pi Imager ein Image auf einer neuen Micro-SD-Karte (Der Pi Imager bietet das aktuelle Image direkt im Menü an - etwas versteckt...) Wenn es um einen Pi4 geht, der 4 GByte RAM (oder mehr) hat, bietet sich das 64-Bit-Image an:
OS wählen -> Other specific-purpose OS -> Home assisteants and home automation -> openHAB -> openHABian (64 bit)
Für die 2 GByte-Variante wäre die 32-Bit-Version besser, weil sie etwas weniger Speicher benötigt. Dafür gibt es hier andere Einschränkungen, insbesondere wenn Du JavaScript Scripting verwenden willst (oder auch Blockly, das nutzt ebenfalls JSS), da bedeutet die 32-Bit-Version evtl. minutenlange Verzögerung von Rules...

Nachdem Du das Image auf die Micro-SD-Karte geschrieben hast, kopierst Du in Schritt 2 das aktuelle Backup unter dem Namen initial.zip auf die erste Partition der Micro-SD-Karte (das ist auch die einzige, die von Windows aus regulär erreichbar ist).
Außerdem bearbeitest Du die Datei openhabian.conf, welche sich ebenfalls auf dieser Partition befindet, und passt die Datei nach Deinen Wünschen an - insbesondere kommentierst Du die Zeile # initialconfig=/boot/initial.zip ein (d.h. Du entfernst die # zu Beginn der Zeile und schaltest die Zeile damit scharf). Die erste Partition des Micro-SD-Karte erscheint im Verzeichnis /boot/ wenn das System mal läuft.
Wenn Du nun als Schritt 3 von der Karte bootest, wird openHABian zunächst das Dateisystem expandieren (mit reboot verbunden) und anschließend openHAB und die Zusatzprogramme installieren sowie das Backup einspielen.
Wenn alles glatt läuft, sollte anschließend das System komplett eingerichtet zur Verfügung stehen.

Falls es doch zu seltsamem Verhalten kommt, wären die wichtigsten Schritte von der GNU/Linux Shell aus (z.B. mittels PuTTY):

Code: Alles auswählen

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

Der Start wird dann ungewöhnlich lange dauern, da openHAB den Cache neu füllen muss, das System sollte dann aber sicher wieder laufen.

[Ede24]

Super und danke erneut für die ausführliche Antwort und Beschreibung
Wenn es wirklich so einfach ist, dann läuft es für mich sehr wahrscheinlich auf die Neuinstallation hinaus.
Damit kann ich dann alten RPI 3 solange laufen lassen bis ich den neuen RPI 4 neu aufgesetzt habe.

2 Fragen noch zur Neuinstallation:
Muss ich Mosquitto und meine Bindings manuell neu installieren und konfigurieren oder geschieht das alles automatisch durch das Einspielen des Backups?

Dein Hinweis zu den Einschränkungen beim RPI 4 mit 2 GB und der 32-Bit-Version gibt mir etwas zu Denken.
Ich plane tatsächlich mit einem RPI 4 mit 2 GB, da ich dachte, kommend vom RPI 3 mit 1 GB wäre das ein gutes Upgrade.
Allerdings habe ich alle meine Regeln mit Blockly programmiert, weshalb ich mir nun nicht mehr sicher bin, ob ich nicht gleich zur 4 GB Variante greifen sollte...
Du schreibst von minutenlanger Verzögerung bei der Ausführung von Regeln.
In welchem Zusammenhang treten diese Verzögerungen denn auf?
Mit meinem RPI 3 sind mir bislang keine solchen Verzögerungen aufgefallen und der hat ja nur 1 GB.
Sollte der RPI 4 mit 2 GB (und 32-Bit-Version) dann nicht ausreichend sein oder könnte ich nach dem Umstieg trotzdem plötzlich diese Probleme bekommen?

Viele Grüße Edmont

[Ede24]

Edit: Habe mich zu dem Thema verzögerte Ausführung der Rules, mal eingelesen. Es betrifft ja nur die erste Ausführung der Rules nach einer Änderung.
Dieses Verhalten ist mir auch schon bei meinem RPI 3 aufgefallen und teilweise etwas nervig aber verschmerzbar.

Habe auch gelesen, dass die 64-Bit-Version auch mit dem RPI 4 2 GB laufen sollte, wenn man nicht zu viele Things, Items und Rules hat.
Ich habe 140 Things, die meisten davon für Modbus, 250 Items und 15 Rules.
Ich denke damit sollte ich mit 64-Bit auch bei nur 2 GB keine Probleme bekommen.

Was meinst du bzw. was würdest du empfehlen?
32-Bit-Version, dafür die verzögerte Ausführung der Rules oder 64-Bit-Version mit etwas knappem RAM?

Viele Grüße Edmont

[udo1toni]

Muss ich Mosquitto und meine Bindings manuell neu installieren und konfigurieren oder geschieht das alles automatisch durch das Einspielen des Backups?

Die Bindings sollten automatisch eingerichtet werden, es ist ja Teil der Konfiguration, welche Bindings Du nutzt.
Manuell installierte Bindings, also solche, deren *.jar Datei Du unter $OPENHAB_HOME/addons/ selbst abgelegt hast, musst Du allerdings ziemlich sicher selbst wieder in das Verzeichnis packen.
Mosquitto ist ein Dienst, der durch openhabian-config installiert werden kann. Den musst Du dann auch genauso wieder einrichten, aber das geht ja fix. Falls Du eine spezielle Konfiguration dazu eingerichtet hast (z.B. spezielle Passworte usw.), kannst Du die entsprechende Konfiguration auf dem Altsystem sichern und ins Neusystem übernehmen (nachdem Du den Dienst installiert hast). Mosquitto musst Du dazu natürlich kurz anhalten und nach dem Restore wieder starten.
Wenn Du keine besonderen Vorkehrungen triffst, wird allerdings die IP Deines neuen Pi eine andere sein als bisher, Du wirst dann also auf allen mqtt Geräten die IP anpassen müssen.

Was meinst du bzw. was würdest du empfehlen?
32-Bit-Version, dafür die verzögerte Ausführung der Rules oder 64-Bit-Version mit etwas knappem RAM?

Im Grunde wäre meine Empfehlung, einen Pi mit 4 oder 8 GByte zu nehmen dann hast Du Ruhe. Aber wenn der Pi 4 mit 2 GByte RAM schon da ist, muss das ja auch nicht sein. Ich habe keine eigene Erfahrung mit der 2 GByte Version und 64 Bit OS, aber mein LXC (Container auf einem Proxmox Host) nimmt sich von den 3 zugeteilten GByte RAM knappe 2 GByte und läuft damit stabil.
Ich nutze 146 Things mit 1464 Items und 64 (DSL) Rules. Die Anzahl Items ist dabei ein wesentlicher Faktor für die benötigte Menge RAM.
Andererseits benötigt ein LXC fast kein RAM für das OS, ein laufendes Samba mitsamt CUPS für mehrere Netzwerkdrucker incl. PDF benötigt nicht mal 100 MByte komplett, so als Größenordnung.

Meine ganz klare Aussage zu dem Thema wäre also: probiere ruhig die 64 Bit Variante aus. Sei aber innerlich darauf vorbereitet, dass das System nicht so zuverlässig läuft wie gedacht, dann musst Du halt auf die 32 Bit Variante wechseln.

Ein anderer Punkt in dem Zusammenhang ist auch, dass Du über /etc/default/openhab und dort über den Parameter EXTRA_JAVA_OPTS Beschränkungen hinsichtlich der maximalen Speichernutzung setzen kannst.
Die normale Einschränkung wäre

Code: Alles auswählen

EXTRA_JAVA_OPTS="-Xms250m -Xmx350m"

was aber nicht explizit in der Zeile stehen muss. Über den Parameter können diverse Einstellungen beim Start mit übergeben werden (z.B. auch welche Interfaces genutzt werden können), falls bei Dir da schon etwas anderes drin steht, musst Du die Zeile um die Parameter ergänzen, so Xms und Xmx noch nicht mit aufgeführt sind. Die Standardwerte beziehen sich auf ein 32 Bit System, da braucht es also für 64 Bit definitiv etwas mehr (aber auch nicht sooo viel mehr)

[Ede24]

Nochmals vielen Dank für den ganzen Input und die ausführlichen Beschreibungen. Ich werde mich am Sonntag mal an die Neuinstallation wagen.
Mit deiner Anleitung habe ich aber keine Bedenken, dass es es nicht klappt
Ich melde mich sobald alles wieder läuft.

Hast du noch eine Empfehlung bzgl der maximalen Speichernutzung? Welche Werte sind bei 64 bit und 2 GB RAM sinnvoll? Bzw. wie finde ich heraus was "zu viel" und was "zu wenig" ist?

Vielen Dank und ein schönes Wochenende.
Viele Grüße Edmont

[udo1toni]

Ich habe keine eigene Erfahrung mit der 2 GByte Version und 64 Bit OS

Mein Tipp wäre, mit

Code: Alles auswählen

-Xms350m -Xmx512m

zu starten, aber das ist ein reines Bauchgefühl

[Ede24]

Guten Abend,

Wollte mich noch Mal melden.
Der Umzug auf den neuen RPI 4 hat soweit gut geklappt und ging schneller als gedacht.
Leider wurde die Config aus Backup-Datei nicht direkt beim ersten Start übernommen. Ich habe es 2x probiert, beide Male mit dem gleichen Ergebnis.
Manuell konnte ich das Backup aber problemlos einspielen und nach der Installation von Mosquitto lief schon alles wieder wie vorher.
Die maximale Speichernutzung war auf Xms192m -Xmx768m voreingestellt. Diese habe ich nun auf Xms350m -Xmx512m geändert.
Mal sehen wie sich die nächsten Tage alles verhält.

Erneut nochmal vielen Dank für die Hilfe und die ausführlichen Erklärungen.
Auch wenn ich das eigentliche Problem nicht gelöst habe, so bin ich jetzt doch froh, das als Anstoß genommen zu haben, mein System neu aufzusetzen und upzugraden.

VG Edmont