Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Holzlenkrad]

Mein Logfile wird leider mit

Code Auswählen Erweitern

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
vollgespammt.

Ich vermute, dass irgendwie mal von einem Rechner mit deutschen Locales auf die Console des Containers oder so zugriffen wurde? Wie kann ich das denn fixen?

[kadettilac89]

Mein Logfile wird leider mit

Code Auswählen Erweitern

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
vollgespammt.

Ich vermute, dass irgendwie mal von einem Rechner mit deutschen Locales auf die Console des Containers oder so zugriffen wurde? Wie kann ich das denn fixen?

Setze diese Variablen im Docker-Compose ... oder als Parameter je nach Umgebung

Code Auswählen Erweitern


        environment:
            LANG: "de_DE.UTF-8"
            LC_ALL: "de_DE.UTF-8" 



[Loredo]

Die Umgebung auf Deutsch zu stellen ist wahrscheinlich nicht zielführend.


Zunächst einmal ist das ja auch "nur" eine Warnung.
Allerdings ist die englischen Locales im Image vorgeneriert und wird auch per Default verwendet, von daher habe ich keine Ahnung weshalb das bei dir so ist.
Dieser Fehler tritt bei mir nirgends auf. Was passiert denn mit einem blanken FHEM Container ohne eigene Dateien?
Ansonsten nutzt du vielleicht irgendein Modul, welches auf der Kommandozeile was tut und nicht richtig funktioniert.

[Holzlenkrad]

Ich vermute mal, dass es daran liegt, dass eins der Module welches sich per SSH auf dem Host einloggt um dort die Bluetooth-Schnittstelle zu nutzen, diesen Fehler verursacht.
Edit: Vermutung bestätigt, wenn der SSH Login vom Modul auf dem Docker-Host deaktiviert wird, dann ist die Fehlermeldung weg.

Der Host ist auf deutsch gestellt, der Docker-Container wird dann vermutlich keine deutschen Sprachdateien haben.

An sich funktioniert ja alles, aber das Logfile wird so extrem unübersichtlich, also brauche ich zumindest eine Möglichkeit die Warnung auszuschalten, wenn ich schon die eigentlich Ursache nicht fixe...

[KraxelHuber]

Also "docker logs fhem_slave".
Die Meldungen dort werden dir wahrscheinlich weiterhelfen. Meine Vermutung ist, dass deine Verzeichnisstruktur nicht richtig passt.

Mit deiner Vermutung scheinst du nicht schlecht zu liegen. Das Log zeigt mir immer wieder die folgenden Einträge, wobei das Problem wohl direkt am Anfang beim Namen benannt wird. Es gibt bei mir kein ./log/fhem-2019-05.

Code Auswählen Erweitern

Preparing configuration ... done

Starting FHEM ...
Can't open ./log/fhem-2019-05.log: No such file or directory at fhem.pl line 2763.
Unable to start FHEM process - errorcode 2
Preparing user environment ...
1. Creating group 'fhem' with GID 6061 ...
2. Enforcing GID for group 'bluetooth' to 6001 ...
3. Creating user 'fhem' with UID 6061 ...
4. Enforcing user and group ownership for /opt/fhem to fhem:fhem ...
5. Correcting group ownership for /dev/tty* ...
6. Found GPIO: Correcting group permissions in /dev and /sys to 'gpio' with GID 6002 ...
7. Found I2C: Correcting group permissions in /dev to 'i2c' with GID 6003 ...
8. Updating /etc/sudoers.d/fhem-docker ...
9. Adding gateway.docker.internal to /etc/hosts ...
10. Adding host.docker.internal to /etc/hosts ...
11. Pre-authorizing SSH to Docker host for user 'fhem' ...
12. Updating SSH key pinning and SSH client permissions for user 'fhem' ...

Und woran liegt das? - Das Verzeichnis fhem/log/* wird in der Datei .gitignore ausgeschlossen, d.h. das Verzeichnis wird nicht ins Online Repo gepusht. Bei einem kompletten Neu-Clone ist es dann auch entsprechend nicht mehr da. Ich wundere mich nur, dass das Problem noch nie bei jemand anderem aufgetaucht ist. Schließlich ist diese Zeile in der .gitignore Datei auch Bestandteil des offiziellen Repo auf GitHub.

Wenn ich diese entsprechende Zeile aus der .gitignore Datei entferne, wird das Log Verzeichnis auch ins Online Repo gepusht. Bei mir startet der Container dann auch reibungslos.

Danke auf jeden Fall für den Hinweis mit den Docker Logs. Das war entscheidend!

[kadettilac89]

Die Umgebung auf Deutsch zu stellen ist wahrscheinlich nicht zielführend.


Zunächst einmal ist das ja auch "nur" eine Warnung.
Allerdings ist die englischen Locales im Image vorgeneriert und wird auch per Default verwendet, von daher habe ich keine Ahnung weshalb das bei dir so ist.
Dieser Fehler tritt bei mir nirgends auf. Was passiert denn mit einem blanken FHEM Container ohne eigene Dateien?
Ansonsten nutzt du vielleicht irgendein Modul, welches auf der Kommandozeile was tut und nicht richtig funktioniert.

definition "zielführend"...damit ist die Warnung weg. Hatte die selbe Meldung. Nutze ssh auf den Host intensiv, wollte nur die Warnungen weg haben. Für mich war das der schnellste weg.

[Holzlenkrad]

definition "zielführend"...damit ist die Warnung weg. Hatte die selbe Meldung. Nutze ssh auf den Host intensiv, wollte nur die Warnungen weg haben. Für mich war das der schnellste weg.

Hab jetzt einfach auf meinem Host noch en_US.UTF-8 dazu installiert, bis jetzt war nur en_EN.UTF-8 und de_DE.UTF-8 vorhanden

Das ist vermutlich im Sinne der Problemlösung die sauberste Methode...

[Loredo]

Ich vermute mal, dass es daran liegt, dass eins der Module welches sich per SSH auf dem Host einloggt um dort die Bluetooth-Schnittstelle zu nutzen, diesen Fehler verursacht.
Edit: Vermutung bestätigt, wenn der SSH Login vom Modul auf dem Docker-Host deaktiviert wird, dann ist die Fehlermeldung weg.

Der Host ist auf deutsch gestellt, der Docker-Container wird dann vermutlich keine deutschen Sprachdateien haben.

Anders herum: Der Docker Container ist in Englisch und nimmt seine Sprache beim Login woanders mit. Die Sprache kann nicht dynamisch anhand des Zielhosts ausgewählt werden, weil zu dem Zeitpunkt noch gar nicht klar ist, was der Zielhost macht. Deshalb ist es wichtig und richtig neben der lokalen Sprache immer auch die Standard English Locale zu generieren (en_US.UTF-8), da man ansonsten - wie du siehst - nicht kompatibel ist.


Die korrekte Vorgehensweise ist also eher, dass du auf deinem Docker Host dafür sorgst, dass neben Deutsch auch Englisch zur Verfügung steht.
Wenn du den Docker Container auf Deutsch stellst, dann musst du dir einiger Nebeneffekte bewusst sein. Es gibt FHEM Module, die ihre Spracheinstellung rein über die Systemsprache steuern. Das bedeutet, dass Readingswerte und teilweise auch die Readingsnamen dann auf die deutsche Sprache festgelegt sind und somit nicht mehr zwingend transportabel. Du weichst dann wissentlich von der Standardsprache "Englisch" ab und solltest dir aller Konsequenzen bewusst sein.

Hab jetzt einfach auf meinem Host noch en_US.UTF-8 dazu installiert, bis jetzt war nur en_EN.UTF-8 und de_DE.UTF-8 vorhanden

Das ist vermutlich im Sinne der Problemlösung die sauberste Methode...

Korrekt!

[Loredo]

Ich habe jetzt nochmals einige Verbesserungen was die Sprachunterstützung angeht im Container vorgenommen:
https://github.com/fhem/fhem-docker/blob/d1bb5be9d1669dd4491e63c6882763d9bc9017e4/README.md#tweak-container-settings-using-environment-variables

Das aktualisierte DEV Image baut gerade. Wenn es sich bewährt, wird es in PROD übernommen.


Für Modulautoren, die per SSH auf Fremdsysteme zugreifen, lässt sich schlussfolgern, dass es hilfreich ist, wenn sie vor dem SSH Kommando noch ein "LC_ALL=C" schreiben. Das ist speziell fürs Scripting vorgesehen, so dass ein standardisiertes Verhalten erzwungen werden kann und keine Abhängigkeit zur auf dem Zielsystem installierten Sprachen besteht.

[kotaro]

Ah! Du meinst 'wc -l' mit kleinem 'L', das ist keine 1/Eins


Der Grund fürs unhealthy steht ja im Docker Statusfeld drin. Wahrscheinlich hast du kein Telnet device, was ohne Passwort auf localhost und Port 7072 horcht.

So nun konnte ich das Problem größtenteils beheben....
jetzt ist der Lesevorgang nicht mehr ständig aktiv. Scheinbar ist mein Log-File vollgelaufen, und der wc -l Befehl hat den Raspi so ausgelastet, das es zu erheblichen verzögerungen gekommen ist...
Hab jetzt erstmal auf Tagslog (werde noch auf Wochenlog wechseln) und jetzt ist der Befehl unter htop nicht mal mehr zu finden...
nur zur Info, falls jemand auch das Problem hat...

[patlabor]

Hallo nochmal,

habe gerade versucht meinen Mi Vacuum in mein unter Docker laufendes fhem einzubinden.
Leider fehlt hierzu ein Perl Modul.

Code Auswählen Erweitern

Crypt::Cipher::AES or Crypt::Rijndael_PP is required!
Ich kann es natürlich von Hand nachinstallieren, dann klappt auch alles wunderbar, einmal einen neuen Container erstellt und alles ist wieder weg. Da die Installation (auf meinem Raspi) leider auch ziemlich zeitaufwendig ist, ist es auch nur eine Notlösung das ganze per Script zu lösen.
Ist es möglich das entsprechende Modul mit ins Containerimage zu übernehmen?

[Loredo]

Die selben zeitlichen Schwierigkeiten, wie du bei deinem lokalen Rapi hast, gibt es beim Bau des Images auf dem Server ebenfalls. Laufzeiten sind dort jedoch zusätzlich beschränkt, so dass Perl Module, die sehr lange zum kompilieren brauchen, nicht mit enthalten sind. Das betrifft ganz besonders sehr viele Crypto Perl Module. Hinzu kommt, dass ganz besonders diese Perl Module dann häufig auch nicht stabil oder gar nicht kompilieren, besonders wenn es sich um die Geräteplattform ARM handelt und diese nur auf einer x86_64 CPU über QEMU emuliert wird.


Crypt::Rijndael_PP als pure Perl Implementierung (--> "_PP" am Ende) scheint mir recht neu zu sein und ist mir bisher nicht als Abhängigkeit aufgefallen. Hier ist zu hoffen, dass die Installation nicht lange dauert. Ich schaue mal, ob das Image so noch baut. Es kann aber jederzeit sein, dass das Modul nicht mehr baut und es sich nicht beheben lässt. In dem Fall wird es dann wieder aus dem Image verschwinden - entweder ganz oder zumindest für die ARM Plattformen. Daher ist der langfristige Rat, dass du dich von deiner ARM Abhängigkeit löst.




Edit: Neues PROD Image mit Crypt::Rijndael_PP (auch für ARM) baut gerade.

[Feinfinger]

Hallo zusammen,

Ich nutze das Fhem-Basis Image in der aktuellen Version.

Leider geht seit einigen Tagen das echodevice von mwinkler nicht mehr, anscheinend hat sich der Amazon Login geändert.

Das workaround, npm zu installieren scheitert leider.

Code Auswählen Erweitern

root@0722932d1695:/opt/fhem# sudo npm install --prefix /opt/fhem/cache/alexa-cookie alexa-cookie2
npm WARN saveError ENOENT: no such file or directory, open '/opt/fhem/cache/alexa-cookie/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/opt/fhem/cache/alexa-cookie/package.json'
npm WARN alexa-cookie No description
npm WARN alexa-cookie No repository field.
npm WARN alexa-cookie No README data
npm WARN alexa-cookie No license field.

Dieser Fehler wird ausgegeben, wenn ich es in der Shell des Fhem-Containers ausführe.

Kann mir jemand helfen?

Gruß Feinfinger

[Dirk070]

Hallo zusammen,

ich habe das Docker-Image auf der Syno installiert. Aktuell habe ich Fhem noch direkt auf der Syno unter ActivePerl laufen.
Also die aktuelle Installation im Paket-Manager angehalten, damit nicht 2 Fhem-Instanzen laufen.

Dann den Container analog dieser Einstellungen hier eingerichtet: https://github.com/oznu/docker-homebridge/wiki/Homebridge-on-Synology
Dazu das Volume "fhem" unterhalb von Docker angelegt und die Inhalte des Verzeichnis /volume1/@appstore/fhem/opt nach /volume1/docker/fhem kopiert.

Soweit so gut, Fhem läuft. Toll (bin Anfänger bzgl. Docker!)

Aber: folgender Fehler erscheint alle 20 Sekunden im Log:

Code Auswählen Erweitern

ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 723) line 1.

Kann mir jemand helfen herauszufinden, was da schief läuft?

Danke Euch und viele Grüße
Dirk

[Loredo]

Beim Start des Containers wird normalerweise das FHEM Modul 99_DockerImageInfo.pm in das ./FHEM Verzeichnis kopiert. Darin ist besagte Funktion enthalten, die für das Monitoring bzw. den Health Check von Docker verwendet wird.


Ich vermute stark, dass die Datei nicht kopiert werden konnte, weil irgendwas mit den Zugriffsrechten des Benutzers, unter dem der Docker Prozess läuft, nicht stimmt. Das ist aber in jedem Fall eine Synology spezifische Angelegenheit, bei der ich nicht helfen kann, da ich kein solches Gerät besitze.