Moin Zusammen, ich habe mein FHEM nach k3s portiert. Soweit klappt auch alles, bis
auf den Health Check. Irgendwie stören mich die Meldungen im Log :-)
│
image: ghcr.io/fhem/fhem-docker:5.2.2-bookworm
2025.11.03 06:11:28.694 1: Read result file: Cannot open /tmp/health-check.result: No such file or directory
root@k3s-server-3:/opt/fhem# cd /tmp
root@k3s-server-3:/tmp# ls -lart
total 12
drwxr-xr-x 1 root root 4096 Nov 3 06:07 ..
drwxrwxrwt 1 root root 4096 Nov 3 06:07 .
-rw-r----- 1 fhem fhem 39 Nov 3 06:07 health-check.urls
root@k3s-server-3:/tmp# cat health-check.urls
http://localhost:8083/fhem/healthcheck
root@k3s-server-3:/tmp#│
Ein manueller curl auf den die Adresse http://localhost:8083/fhem/healthcheck klappt ohne Probleme.
Gibt es irgend etwas zu beachten?
Wie kann ich den healthcheck, zur Not, abschalten?
Zum Healthcheck kann ich nichts sagen, aber die Fehlermeldung lautet:
...Cannot open /tmp/health-check.resultDu schaust dir aber "/tmp/health-check.urls" an, die andere gibt's nicht (sagt ja auch die Meldung).
Zitat von: RalfRog am 03 November 2025, 09:23:59Zum Healthcheck kann ich nichts sagen, aber die Fehlermeldung lautet:
...Cannot open /tmp/health-check.resultDu schaust dir aber "/tmp/health-check.urls" an, die andere gibt's nicht (sagt ja auch die Meldung).
Stimmt und das ist ja auch das Problem. In der urls Datei steht die zu prüfende URL korrekt drin, allerdings wird die Ausgabe Datei nicht erstellt. Das ist das Problem!
Ist jetzt zwar ein "shot in the dark", aber was sagt
list DockerImageInfo (bzw. was steht in den beiden INTERNALs zum healthcheck?)
Wahrscheinlich ist da aber irgendwo etwas anderes falsch. Poste mal rein zur Sicherheit dein compose file.
Du kannst sonst aber auch mal auf GitHub (https://github.com/fhem/fhem-docker) suchen, woher genau diese Read result file-Fehlermeldung kommt, vielleicht gibt das ja schon einen Hinweis auf die Fehlerquelle. Ich schaffe das frühestens Morgen.
Das health Check kommt doch aus dem Container Image wenn ich das richtig sehe.
Wie hast du hast fhem im k3s deployt? Hast Du ein Helm Chart genommen oder alle Ressourcen von Hand als Manifest File angelegt?
Zitat von: passibe am 03 November 2025, 13:29:46Ist jetzt zwar ein "shot in the dark", aber was sagt
list DockerImageInfo (bzw. was steht in den beiden INTERNALs zum healthcheck?)
Wahrscheinlich ist da aber irgendwo etwas anderes falsch. Poste mal rein zur Sicherheit dein compose file.
Du kannst sonst aber auch mal auf GitHub (https://github.com/fhem/fhem-docker) suchen, woher genau diese Read result file-Fehlermeldung kommt, vielleicht gibt das ja schon einen Hinweis auf die Fehlerquelle. Ich schaffe das frühestens Morgen.
In einem Kubernetes Cluster, was k3s ist, gibt es kein Composer File. Es ist kein Docker ;)
Zitat von: CoolTux am 03 November 2025, 13:35:50In einem Kubernetes Cluster, was k3s ist, gibt es kein Composer File. Es ist kein Docker ;)
Oh sorry, das hatte ich nicht gecheckt :D Ich dachte er ist von kubernetes nach normal-Docker umgezogen 🤦🏼
Zitat von: CoolTux am 03 November 2025, 13:34:53Das health Check kommt doch aus dem Container Image wenn ich das richtig sehe.
Wie hast du hast fhem im k3s deployt? Hast Du ein Helm Chart genommen oder alle Ressourcen von Hand als Manifest File angelegt?
Alles als Manifest!
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fhem
namespace: fhem
spec:
replicas: 1
selector:
matchLabels:
app: fhem
template:
metadata:
labels:
app: fhem
spec:
hostNetwork: true # Use host network to allow direct access to devices
containers:
- name: fhem
image: ghcr.io/fhem/fhem-docker:5.2.2-bookworm
env:
- name: TZ
value: "Europe/Berlin"
ports:
- containerPort: 8083
volumeMounts:
- name: fhem-data
mountPath: /opt/fhem
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
livenessProbe:
httpGet:
path: /fhem/healthcheck
port: 8083
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 8083
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
volumes:
- name: fhem-data
persistentVolumeClaim:
claimName: fhem-pvc
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fhem
namespace: fhem
spec:
replicas: 1
selector:
matchLabels:
app: fhem
template:
metadata:
labels:
app: fhem
spec:
hostNetwork: true # Use host network to allow direct access to devices
containers:
- name: fhem
image: ghcr.io/fhem/fhem-docker:5.2.2-bookworm
env:
- name: TZ
value: "Europe/Berlin"
ports:
- containerPort: 8083
volumeMounts:
- name: fhem-data
mountPath: /opt/fhem
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
livenessProbe:
httpGet:
path: /fhem/healthcheck
port: 8083
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 8083
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
volumes:
- name: fhem-data
persistentVolumeClaim:
claimName: fhem-pvc
Ja es gibt kein compose File, nur ein Manifest.
Hier noch das gewünscht List:
Internals:
FUUID 69072fb2-f33f-8b1e-fd94-e2cf62967e246ab8
INFO_DIR /tmp
NAME DockerImageInfo
NR 59
NTFY_ORDER 50-DockerImageInfo
RESULT_FILE /tmp/health-check.result
STATE
TYPE DockerImageInfo
URL_FILE /tmp/health-check.urls
eventCount 1
READINGS:
2025-11-02 10:38:36 container.cap.e audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
2025-11-02 10:38:36 container.cap.i none
2025-11-02 10:38:36 container.cap.p audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot
2025-11-03 12:44:15 container.hostname raspberrypi5
2025-11-03 12:44:15 container.hostnetwork 1
2025-11-02 10:38:36 container.privileged 0
2025-11-02 10:38:36 id.gid 6061
2025-11-02 10:38:36 id.gname fhem
2025-11-02 10:38:36 id.groups [ "fhem": 6061, "tty": 5, "mail": 8, "dialout": 20, "audio": 29, "video": 44, "bluetooth": 6001, "gpio": 6002 ]
2025-11-02 10:38:36 id.uid 6061
2025-11-02 10:38:36 id.uname fhem
2025-11-02 10:38:36 image.created 2025-10-26T07:02:47.172Z
2025-11-02 10:38:36 image.description A full blown Docker image for FHEM house automation system, based on Debian Perl -bookworm.
2025-11-02 10:38:36 image.documentation https://github.com/fhem/fhem-docker/blob/b1f9552f0bb2731f32ba3dd8209dcbe8626c625a/README.md
2025-11-02 10:38:36 image.licenses MIT
2025-11-02 10:38:36 image.revision b1f9552f0bb2731f32ba3dd8209dcbe8626c625a
2025-11-02 10:38:36 image.source https://github.com/fhem/fhem-docker/
2025-11-03 12:44:15 image.title fhem-linux/arm64
2025-11-03 12:44:15 image.url https://hub.docker.com/r/fhem/fhem-linux/arm64
2025-11-02 10:38:36 image.vendor FHEM
2025-11-02 10:38:36 image.version 5.2.2-bookworm
2025-11-02 10:38:36 ssh-id_ed25519.pub <REDACTED>
2025-11-02 10:38:36 ssh-id_rsa.pub <REDACTED>
2025-11-02 10:38:36 sudoers [ "#", "# Allow installation of new packages", "# Allow updates", "# Auto-generated during container start", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm install *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm uninstall *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm update *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/local/bin/cpanm *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -q update", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -s -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y install *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/nmap", "# required by modules" ]
Attributes:
alias Docker Image Info
devStateIcon ok.*:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red
group System
icon docker@grey
room System->Dienste
Deine erwähnte und störende Logmeldung ist doch aus dem fhem Log oder?
Kommt also von einem fhem Device. Ich würde das DockerImageInfo einfach rauswerfen. Ist bestimmt nur Kosmetischer Natur.
Zitat von: CoolTux am 03 November 2025, 19:54:19Deine erwähnte und störende Logmeldung ist doch aus dem fhem Log oder?
Kommt also von einem fhem Device. Ich würde das DockerImageInfo einfach rauswerfen. Ist bestimmt nur Kosmetischer Natur.
Wird leider nichts bringen, denn es wird frecherweise immer wieder beim Container Start reinkopiert.
COPY src/FHEM/99_DockerImageInfo.pm /fhem/FHEM/
Kann doch ist ja nicht schlimm, ist doch nur die Moduldatei. Schmeiß das define einfach aus die Konfig.
Zitat von: CoolTux am 03 November 2025, 20:41:04Kann doch ist ja nicht schlimm, ist doch nur die Moduldatei. Schmeiß das define einfach aus die Konfig.
Ich sagte doch, das es nichts bringen wird, da die Datei beim Container Start immer wieder ins FHEM Verzeichnis kopiert wird.
Alles klar
Kenne mich mit Kubernetes überhaupt nicht aus, deshalb sorry, wenn das, was jetzt folgt, dumme Ideen sind, aber:
Wie spielen der im Dockerfile in Zeile 255 definierte HEALTHCHECK (https://github.com/fhem/fhem-docker/blob/228306b8e9bcab517667218af52b7a1e1ac54046/Dockerfile-bookworm#L255) und die livenessProbe aus deinem manifest zusammen?
Zitat von: P.A.Trick am 03 November 2025, 18:56:48livenessProbe:
httpGet:
path: /fhem/healthcheck
port: 8083
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
Vielleicht "maskiert" diese livenessProbe den HEALTHCHECK, sodass dieser gar nicht ausgeführt wird und dann natürlich auch keine results-Datei angelegt wird?
Anders gefragt: Läuft bei dir im Image überhaupt health-check.sh? Meine Vermutung ist, nein.
Nochmal anders gefragt: Kannst du die livenessProbe irgendwie anpassen, dass da nicht mit httpGet gearbeitet wird, sondern ein Skript innerhalb des Containers (ist Container bei Kubernetes überhaupt der richtige Begriff?) ausgeführt wird?
Also, dass die livenessProbe einfach selbst alle paar Sekunden /health-check.sh ausführt?
Dabei sehe ich grade aber auch, dass DockerImageInfo ein Attribut "DockerHealthCheck" für alle FHEMWEB-Devices hinzufügt (Zeile 84 (https://github.com/fhem/fhem-docker/blob/228306b8e9bcab517667218af52b7a1e1ac54046/src/FHEM/99_DockerImageInfo.pm#L84)); vielleicht reicht es also auch, wenn du bei allen FHEMWEB-Devices DockerHealthCheck auf 0 setzt. Angenommen du hast nur ein FHEMWEB-Device hilft vielleicht schon ein:
attr WEB DockerHealthCheck 0
Zitat von: passibe am 04 November 2025, 00:08:53Kenne mich mit Kubernetes überhaupt nicht aus, deshalb sorry, wenn das, was jetzt folgt, dumme Ideen sind, aber:
Wie spielen der im Dockerfile in Zeile 255 definierte HEALTHCHECK (https://github.com/fhem/fhem-docker/blob/228306b8e9bcab517667218af52b7a1e1ac54046/Dockerfile-bookworm#L255) und die livenessProbe aus deinem manifest zusammen?
Zitat von: P.A.Trick am 03 November 2025, 18:56:48livenessProbe:
httpGet:
path: /fhem/healthcheck
port: 8083
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
Vielleicht "maskiert" diese livenessProbe den HEALTHCHECK, sodass dieser gar nicht ausgeführt wird und dann natürlich auch keine results-Datei angelegt wird?
Anders gefragt: Läuft bei dir im Image überhaupt health-check.sh? Meine Vermutung ist, nein.
Nochmal anders gefragt: Kannst du die livenessProbe irgendwie anpassen, dass da nicht mit httpGet gearbeitet wird, sondern ein Skript innerhalb des Containers (ist Container bei Kubernetes überhaupt der richtige Begriff?) ausgeführt wird?
Also, dass die livenessProbe einfach selbst alle paar Sekunden /health-check.sh ausführt?
Dabei sehe ich grade aber auch, dass DockerImageInfo ein Attribut "DockerHealthCheck" für alle FHEMWEB-Devices hinzufügt (Zeile 84 (https://github.com/fhem/fhem-docker/blob/228306b8e9bcab517667218af52b7a1e1ac54046/src/FHEM/99_DockerImageInfo.pm#L84)); vielleicht reicht es also auch, wenn du bei allen FHEMWEB-Devices DockerHealthCheck auf 0 setzt. Angenommen du hast nur ein FHEMWEB-Device hilft vielleicht schon ein:attr WEB DockerHealthCheck 0
Das Attribut DockerHealthcheck habe ich ausprobiert, allerdings hat es nichts geändert.
Danke für deine Gedanken, aber ich hatte jetzt keine Lust mehr weiter zu probieren und habe es mit
einem Kubernetes post command gefixt.
Nicht schön, aber besser als diese nervigen Meldungen.
containers:
- name: fhem
image: ghcr.io/fhem/fhem-docker:5.2.2-bookworm
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
Hi, ich habe den Beitrag erst heute gesehen.
Es ist so, dass im container ein health-check script liegt.
Das script prüft, ob der container noch antwortet. Es legt auch health-check.result an.
Ich habe kein kubernetes zum testen, aber so sollte der health check aussehen, damit das script verwendet wird:
livenessProbe:
exec:
command:
- /bin/bash
- /health-check.sh # Pfad zum Skript im offiziellen Image
initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
periodSeconds: 60 # Häufigkeit der Prüfung
timeoutSeconds: 15 # Skript-Laufzeit abwarten
failureThreshold: 3 # Neustart nach 3 Fehlversuchen
Zitat von: Sidey am 12 April 2026, 16:39:46Hi, ich habe den Beitrag erst heute gesehen.
Es ist so, dass im container ein health-check script liegt.
Das script prüft, ob der container noch antwortet. Es legt auch health-check.result an.
Ich habe kein kubernetes zum testen, aber so sollte der health check aussehen, damit das script verwendet wird:
livenessProbe:
exec:
command:
- /bin/bash
- /health-check.sh # Pfad zum Skript im offiziellen Image
initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
periodSeconds: 60 # Häufigkeit der Prüfung
timeoutSeconds: 15 # Skript-Laufzeit abwarten
failureThreshold: 3 # Neustart nach 3 Fehlversuchen
Vielen Dank aber ich kann sagen das es super unter k3s läuft:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: fhem
namespace: fhem
spec:
replicas: 1
selector:
matchLabels:
app: fhem
template:
metadata:
labels:
app: fhem
spec:
hostNetwork: true # Use host network to allow direct access to devices
containers:
- name: fhem
image: ghcr.io/fhem/fhem-docker:5.2.7-bookworm
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
env:
- name: TZ
value: "Europe/Berlin"
ports:
- containerPort: 8083
volumeMounts:
- name: fhem-data
mountPath: /opt/fhem
resources:
requests:
cpu: "100m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
livenessProbe:
httpGet:
path: /fhem/healthcheck
port: 8083
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 5
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 8083
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
volumes:
- name: fhem-data
persistentVolumeClaim:
claimName: fhem-pvc
Du legst eine leere Datei health-check.result an.
In der Datei soll das Ergebnis vom Health Check stehen.
Das Script legt es an und berücksichtigt noch, dass es mehrere FHEMWeb Instanzen geben können und auch unter welchem Pfad die Erreichbar sind.
Folglich kann Docker Image Info damit nicht arbeiten.
Deiner Variante fehlt das. Das muss kein Problem sein, kann aber mal eines werden.
Grüße Sidey
Zitat von: Sidey am 12 April 2026, 21:26:07Du legst eine leere Datei health-check.result an.
In der Datei soll das Ergebnis vom Health Check stehen.
Das Script legt es an und berücksichtigt noch, dass es mehrere FHEMWeb Instanzen geben können und auch unter welchem Pfad die Erreichbar sind.
Folglich kann Docker Image Info damit nicht arbeiten.
Deiner Variante fehlt das. Das muss kein Problem sein, kann aber mal eines werden.
Grüße Sidey
Genau das mache ich ja und funktioniert super!
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
Zitat von: P.A.Trick am 13 April 2026, 17:18:42Genau das mache ich ja und funktioniert super!
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
Ich interpretiere das so, dass nach dem Starten des Containers immer ein 'ok' in /tmp/health-check.result geschrieben wird.
Egal wie sich der Zustand verändert oder wie viele FHEMWEB Instanzen es auch gibt.
Das macht das Healthcheck script so nicht.
Du hast eine Fehlermeldung mit diesem Workaround unterdrückt. Das funktioniert super, das verstehe ich.
Ich wollte nur darauf hinweisen, dass dein Workaround die Funktion des healthcheck script nicht abbildet und dass dies nicht der empfohlene Weg ist den Healthcheck des containers zu realisieren.
Du kannst es natürlich für dich so belassen.
Der Nächste User, der über die Lösung stolpert, sollte es einordnen können, dass es nicht der empfohlene Weg ist, health-check.result manuell zu mocken.
Grüße Sidey
Zitat von: Sidey am 13 April 2026, 21:52:11Zitat von: P.A.Trick am 13 April 2026, 17:18:42Genau das mache ich ja und funktioniert super!
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo 'ok' > /tmp/health-check.result"]
Ich interpretiere das so, dass nach dem Starten des Containers immer ein 'ok' in /tmp/health-check.result geschrieben wird.
Egal wie sich der Zustand verändert oder wie viele FHEMWEB Instanzen es auch gibt.
Das macht das Healthcheck script so nicht.
Du hast eine Fehlermeldung mit diesem Workaround unterdrückt. Das funktioniert super, das verstehe ich.
Ich wollte nur darauf hinweisen, dass dein Workaround die Funktion des healthcheck script nicht abbildet und dass dies nicht der empfohlene Weg ist den Healthcheck des containers zu realisieren.
Du kannst es natürlich für dich so belassen.
Der Nächste User, der über die Lösung stolpert, sollte es einordnen können, dass es nicht der empfohlene Weg ist, health-check.result manuell zu mocken.
Grüße Sidey
Ja da gebe ich dir recht, dass es "nur" ein Workaround ist. Hast du eine alternative Lösung die unter k3s lauffähig ist?
Zitat von: P.A.Trick am 13 April 2026, 21:57:54Ja da gebe ich dir recht, dass es "nur" ein Workaround ist. Hast du eine alternative Lösung die unter k3s lauffähig ist?
Ich nehme an, mein Vorschlag aus dem Beitrag hier sollte laufen:
https://forum.fhem.de/index.php?topic=142936.msg1361815#msg1361815
Mangels eigenem Kubernetes konnte ich es nicht testen.
Zitat von: Sidey am 13 April 2026, 22:18:59Zitat von: P.A.Trick am 13 April 2026, 21:57:54Ja da gebe ich dir recht, dass es "nur" ein Workaround ist. Hast du eine alternative Lösung die unter k3s lauffähig ist?
Ich nehme an, mein Vorschlag aus dem Beitrag hier sollte laufen:
https://forum.fhem.de/index.php?topic=142936.msg1361815#msg1361815
Mangels eigenem Kubernetes konnte ich es nicht testen.
So ich habe die Einstellungen übernommen und sie klappen perfekt.
Service Account: default │
│ Node: k3s-server-1/192.168.1.222 │
│ Start Time: Tue, 14 Apr 2026 07:05:22 +0200 │
│ Labels: app=fhem │
│ pod-template-hash=649f48d9fc │
│ Annotations: <none> │
│ Status: Running │
│ IP: 192.168.1.222 │
│ IPs: │
│ IP: 192.168.1.222 │
│ Controlled By: ReplicaSet/fhem-649f48d9fc │
│ Containers: │
│ fhem: │
│ Container ID: containerd://53abd982b9e0a2ee677ac359eb02e10e92cffd48877fa0808c8a2c7db2d65b33 │
│ Image: ghcr.io/fhem/fhem-docker:5.2.7-bookworm │
│ Image ID: ghcr.io/fhem/fhem-docker@sha256:31773354d5a940dbda80d82814d6d6fd170ac2b1a808863d4005de4aab987aae │
│ Port: 8083/TCP │
│ Host Port: 8083/TCP │
│ State: Running │
│ Started: Tue, 14 Apr 2026 07:05:22 +0200 │
│ Ready: True │
│ Restart Count: 0 │
│ Limits: │
│ cpu: 500m │
│ memory: 512Mi │
│ Requests: │
│ cpu: 100m │
│ memory: 256Mi │
│ Liveness: exec [/bin/bash /health-check.sh] delay=60s timeout=15s period=60s #success=1 #failure=3 │
│ Readiness: http-get http://:8083/fhem/healthcheck delay=30s timeout=5s period=15s #success=1 #failure=3 │
│ Environment: │
│ TZ: Europe/Berlin
Guten Morgen
livenessProbe:
exec:
command:
- /bin/bash
- /health-check.sh # Pfad zum Skript im offiziellen Image
initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
periodSeconds: 60 # Häufigkeit der Prüfung
timeoutSeconds: 15 # Skript-Laufzeit abwarten
failureThreshold: 3 # Neustart nach 3 Fehlversuchen
readinessProbe:
httpGet:
path: /fhem
port: fhemweb
initialDelaySeconds: 60
timeoutSeconds: 15
failureThreshold: 3
Ich habe das mal so in mein Helm Chart eingebaut und es scheint sehr gut zu funktionieren.
@P.A.Trick Eventuell hast Du ja Interesse das einmal zu testen. Dann kannst Du mir auch erzählen was ich vielleicht noch einbauen sollte.
Grüße
OhJe zu früh gefreut. Er startet den Container alle 3 Minuten neu.
Grund:
/health-check.sh
Cannot read url file /tmp/health-check.urls
Und tatsächlich gibt es das file gar nicht
ls /tmp/health-check.urls
ls: cannot access '/tmp/health-check.urls': No such file or directory
Also bei mir bleibt die Variable ${fhemUrl} aus dem Script health-check.sh leer. Könnte es daran liegen? Woher bezieht er den Inhalt der Variablen?
Ok ich denke ich habe es gefunden.
DockerImageInfo
Das FHEM Device existiert bei mir nicht. Aber so wie ich das sehe soll das wohl Voraussetzung sein damit der Health Check klappt, korrekt?
Ja das DockerImageInfo ist voraussetzung.
Das sollte aber auch automatisch angelegt werden, außer Du nutzt configDB :)
Grüße Sidey
Oder Du nutzt fhem.cfg.demo
Und Du musst auch noch ein Verzeichnis anlegen
.dockerenv
ansonsten erkennt das DockerImageInfo Modul nicht das es ein Container ist.
Ich denke mal da sollte man mal schauen ob man das optimieren kann.
Leider finde ich keinen weiteren Hinweis auf das Verzeichnis .dockerenv ausser im Modulcode von DockerImageInfo.
Woher sollte das Verzeichnis denn kommen?
Zitat von: CoolTux am 17 April 2026, 07:39:26Guten Morgen
livenessProbe:
exec:
command:
- /bin/bash
- /health-check.sh # Pfad zum Skript im offiziellen Image
initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
periodSeconds: 60 # Häufigkeit der Prüfung
timeoutSeconds: 15 # Skript-Laufzeit abwarten
failureThreshold: 3 # Neustart nach 3 Fehlversuchen
readinessProbe:
httpGet:
path: /fhem
port: fhemweb
initialDelaySeconds: 60
timeoutSeconds: 15
failureThreshold: 3
Ich habe das mal so in mein Helm Chart eingebaut und es scheint sehr gut zu funktionieren.
@P.A.Trick Eventuell hast Du ja Interesse das einmal zu testen. Dann kannst Du mir auch erzählen was ich vielleicht noch einbauen sollte.
Grüße
Ja kann ich gerne machen. Wo finde ich das Chart?
Zitat von: P.A.Trick am 17 April 2026, 12:10:23Zitat von: CoolTux am 17 April 2026, 07:39:26Guten Morgen
livenessProbe:
exec:
command:
- /bin/bash
- /health-check.sh # Pfad zum Skript im offiziellen Image
initialDelaySeconds: 60 # Puffer für das Laden der fhem.cfg
periodSeconds: 60 # Häufigkeit der Prüfung
timeoutSeconds: 15 # Skript-Laufzeit abwarten
failureThreshold: 3 # Neustart nach 3 Fehlversuchen
readinessProbe:
httpGet:
path: /fhem
port: fhemweb
initialDelaySeconds: 60
timeoutSeconds: 15
failureThreshold: 3
Ich habe das mal so in mein Helm Chart eingebaut und es scheint sehr gut zu funktionieren.
@P.A.Trick Eventuell hast Du ja Interesse das einmal zu testen. Dann kannst Du mir auch erzählen was ich vielleicht noch einbauen sollte.
Grüße
Ja kann ich gerne machen. Wo finde ich das Chart?
https://git.cooltux.net/FHEM/fhem-docker_helm-chart
Bin für Verbesserungen sehr offen
Zitat von: CoolTux am 17 April 2026, 08:55:08Leider finde ich keinen weiteren Hinweis auf das Verzeichnis .dockerenv ausser im Modulcode von DockerImageInfo.
Woher sollte das Verzeichnis denn kommen?
Eigentlich ist es eine Datei und jetzt weiss ich, dass die nur von der Docker Engine angelegt wird.
Da muss ich mal ran und eine universellere Erkennung einbauen.
Grüße Sidey