docker image - health check Fehler

Begonnen von P.A.Trick, 03 November 2025, 06:15:01

Vorheriges Thema - Nächstes Thema

P.A.Trick

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 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); 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"]
FHEM + Homeassistant - meine HW -> https://www.trinityonline.de/hardware/

Sidey

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


Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker, WebAuth

P.A.Trick

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
FHEM + Homeassistant - meine HW -> https://www.trinityonline.de/hardware/

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker, WebAuth