FHEM, docker, Container beendet sich

Begonnen von GammaTwin, 05 Februar 2023, 14:29:02

Vorheriges Thema - Nächstes Thema

GammaTwin

Grüße,

ich hatte im Sammelthread https://forum.fhem.de/index.php/topic,89745.0.html das Thema schon einmal angeschnitten. Vielleicht wird es ja eine größere Diskussion, daher ein eigener Thread.

Zitat von: GammaTwin am 21 Januar 2023, 18:24:03
Grüße,

ich habe zum Jahreswechsel von Ubuntu 18 auf 22 gewechselt. Docker wieder in Betrieb genommen und auch fhem/fhem. Lief sehr problemlos :)

Allerdings steigt der Container seitdem häufiger aus, der Container ist dann unhealthy. Die letzte Meldung lautet:
telnetPort: Can't open server port at 7072: Address already in use. Exiting.

Der Container läuft vorher aber tagelang problemlos. Ich habe als Netzwerktyp Host und Brigde probiert.

Zitat von: Wernieman am 21 Januar 2023, 18:35:38
7072: Address already in use.
Läuft bei Dir etwas anderes, was den Port 7072 blockieren könnte?
Eventuell mal als root oder mit sudo (Wenn e zu dem Fehler kommt):
netstat -lntp | grep 7072
ss -tulpe | grep 7072


Zitat von: GammaTwin am 22 Januar 2023, 08:07:42
Dann warte ich mal auf den nächsten "Event" :)

Wenn ich FHEM im Netzwerktyp "Bridge" dürfte der Fehler aber überhaupt nicht auftreten, oder? Ich meine mich zu erinnern, dass dies einmal der Fall gewesen ist.

Der Event ist zwei weitere Male aufgetreten.

Der Fehlerlog von FHEM ähnelt sich auch.
- Es ist immer die line 625 der entry.sh beteiligt.
- Es gibt immer einen Neustart von FHEM
/entry.sh: line 621: kill: (9675) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (9675) - No such process
10/entry.sh: line 625: kill: (9675) - No such process
9/entry.sh: line 625: kill: (9675) - No such process
8/entry.sh: line 625: kill: (9675) - No such process
7/entry.sh: line 625: kill: (9675) - No such process
6/entry.sh: line 625: kill: (9675) - No such process
5/entry.sh: line 625: kill: (9675) - No such process
4/entry.sh: line 625: kill: (9675) - No such process
3/entry.sh: line 625: kill: (9675) - No such process
2/entry.sh: line 625: kill: (9675) - No such process
1/entry.sh: line 625: kill: (9675) - No such process
/entry.sh: line 632: kill: (9675) - No such process
0
Automatic restart ...
/entry.sh: line 645: kill: (9675) - No such process
Preparing configuration ... done
Starting FHEM ...
2023.02.01 00:09:11.249 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2023.02.01 00:09:11.249 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2023.02.01 00:09:11.249 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2023.02.01 00:09:11.249 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2023.02.01 00:09:11.252 1: Including fhem.cfg
2023.02.01 00:09:11.273 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.

/entry.sh: line 621: kill: (16120) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (16120) - No such process
10/entry.sh: line 625: kill: (16120) - No such process
9/entry.sh: line 625: kill: (16120) - No such process
8/entry.sh: line 625: kill: (16120) - No such process
7/entry.sh: line 625: kill: (16120) - No such process
6/entry.sh: line 625: kill: (16120) - No such process
5/entry.sh: line 625: kill: (16120) - No such process
4/entry.sh: line 625: kill: (16120) - No such process
3/entry.sh: line 625: kill: (16120) - No such process
2/entry.sh: line 625: kill: (16120) - No such process
1/entry.sh: line 625: kill: (16120) - No such process
/entry.sh: line 632: kill: (16120) - No such process
0
Automatic restart ...
/entry.sh: line 645: kill: (16120) - No such process
Preparing configuration ... done
Starting FHEM ...
2023.02.05 12:09:11.484 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2023.02.05 12:09:11.484 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2023.02.05 12:09:11.484 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2023.02.05 12:09:11.484 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2023.02.05 12:09:11.487 1: Including fhem.cfg
2023.02.05 12:09:11.513 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.


Anbei noch meine docker compose aus Portainer:
services:
version: '2.4'
    fhem:
        container_name: FHEM-FHEM
        image: fhem/fhem:3-bullseye
        restart: unless-stopped
        ports:
            - "8083:8083"
            - "2121:2121"
        volumes:
            - /home/user/Docker/fhem/fhem/fhem:/opt/fhem
        networks:
            FHEMparts:
                ipv4_address: 192.168.100.2

networks:
  FHEMparts:
    enable_ipv6: false
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.100.0/24
          gateway: 192.168.100.1


Der Container ist im Fehlerfall unhealty, aber erreichbar. Ein Test
netstat -lntp | grep 7072
ergab:
tcp       33      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      -
nach dem Neustart des Conainers
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      -
Bin mir nicht sicher, was dies bedeutet.

Für Hilfe wäre ich sehr dankbar.

kadettilac89

wie ist telnet in fhem definiert?

Beachtet?
https://github.com/fhem/fhem-docker#role-of-the-telnet-device-in-fhem


The Docker container will need to communicate with FHEM to shutdown nicely instead of just killing the process. For this to work properly, a telnet device is of paramount importance. Unless you are using configDB, the container will try to automatically detect and adjust your telnet configuration for it to work. If for any reason that fails or you are using configDB, it is your own obligation to configure such telnet device (define telnetPort telnet 7072). It may listen on the standard port 7072 or can be any other port (see environment variable TELNETPORT to re-configure it).

It is enough for the telnet device to only listen on the loopback device (aka localhost) but it cannot have any password protection enabled for loopback connections. If you require your telnet instance to listen for external connections, it is usually best-practice to set a password for it. In that case, make sure that any allowed device you might have configured for this purpose only requires a password for non-loopback connections (e.g. using attribute globalpassword instead of password - also see allowed commandref). The same applies when using the deprecated attribute password for the telnet device itself (see telnet commandref).

GammaTwin

Ich bin unsicher, da ich die Frage nicht so recht verstehe  ;D

mein telenet Device sieht folgendermaßen aus.
defmod telnetPort telnet 7072 global

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

GammaTwin


kadettilac89

entry.sh stellt nur fest, dass  der fhem-prozess nicht mehr läuft und versucht den zu starten. Telnet hängt dann irgendwo noch rum, darum die vermutlich die telnet Fehlermeldung. Nur Symptom, nicht die Ursache.

Ähnlich wie hier ... https://forum.fhem.de/index.php/topic,89745.msg1143808.html#msg1143808 ... Ursache war ein Modul das fhem gekillt hat. Nicht Docker.

Verbose hoch setzen, Fehlersuche wie bei anderen Fhem Problemen. Anleitungen Wiki + Forum hier genügend oft gepostet. Kann ein fehlendes Paket sein dass in deiner damaligen Installation vorhanden war, mag sein durch Änderungen im Container oder manuelle Nachinstallation.

Z. B.
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
https://wiki.fhem.de/wiki/Hilfe!_Mein_FHEM_funktioniert_nicht!
https://forum.fhem.de/index.php?topic=107794.0



Sidey

Vielleicht sollten wir es docker überlassen, den Container neu zu starten und nicht selbst den FHEM Prozess neu initialisieren.

Ich könnte entry dadurch auch vereinfachen glaube ich.
FHEM Prozess weg = Container weg :)
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

Wernieman

Vor allem, weil der Healthy Prozess sich im Docker-Log bemerkbar macht. (War für mich "damals" einer der Gründe, mir einen Minnimalistischen selber zu bauen)
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

kadettilac89

Zitat von: Sidey am 06 Februar 2023, 18:26:27
Vielleicht sollten wir es docker überlassen, den Container neu zu starten und nicht selbst den FHEM Prozess neu initialisieren.

Ich könnte entry dadurch auch vereinfachen glaube ich.
FHEM Prozess weg = Container weg :)
Vote: Ich bin dafür

Hätte den Vorteil, wenn der Container wegen einen Prozessproblem wegbricht, würde die Restart-Policy always, on error ... auch greifen und den Container neu starten. Aktuell hängt der Healthcheck im ungünstigsten Fall auf unhealthy. Irgend welche Prozessleichen oder blockierte Ports usw. wären auch wieder frei. Im Log sieht man einen Reboot ...

Sidey

Ja, da könnte man sich noch was bezüglich der Logausgaben überlegen.
Momentan werden die ja im Container dupliziert durch das entry Script dupliziert.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

kadettilac89

Zitat von: Sidey am 06 Februar 2023, 20:03:17
Ja, da könnte man sich noch was bezüglich der Logausgaben überlegen.
Momentan werden die ja im Container dupliziert durch das entry Script dupliziert.
Das ist zwar off-topic aber ich kenne auch den Post in github dass nodejs vermutlich raus fällt. Du machst dir Gedanken zum zukünftigen Image. Willst du dazu einen Thread öffnen um solche Ansätze zu diskutieren?

GammaTwin

Grüße,

das klingt sehr gut.

Gibt es einen kurzfristigen Workaround?

Ich hatte schon wieder den Fehler :(

Es beginnt immer mit
/entry.sh: line 621: kill: (9675) - No such process
Abrupt daemon termination, starting 10s countdown

/entry.sh: line 621: kill: (9675) - No such process
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (9675) - No such process
10/entry.sh: line 625: kill: (9675) - No such process
9/entry.sh: line 625: kill: (9675) - No such process
8/entry.sh: line 625: kill: (9675) - No such process
7/entry.sh: line 625: kill: (9675) - No such process
6/entry.sh: line 625: kill: (9675) - No such process
5/entry.sh: line 625: kill: (9675) - No such process
4/entry.sh: line 625: kill: (9675) - No such process
3/entry.sh: line 625: kill: (9675) - No such process
2/entry.sh: line 625: kill: (9675) - No such process
1/entry.sh: line 625: kill: (9675) - No such process
/entry.sh: line 632: kill: (9675) - No such process
0
Automatic restart ...
/entry.sh: line 645: kill: (9675) - No such process
Preparing configuration ... done
Starting FHEM ...
2023.02.07 06:09:38.986 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2023.02.07 06:09:38.986 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2023.02.07 06:09:38.986 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2023.02.07 06:09:38.986 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2023.02.07 06:09:38.989 1: Including fhem.cfg
2023.02.07 06:09:39.017 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.

kadettilac89

Zitat von: GammaTwin am 07 Februar 2023, 06:30:41
Gibt es einen kurzfristigen Workaround?
Was willst du für einen Workaround? Fehler suchen und lösen,nur weil der Container neu startet behebt das dein Problem nicht.

Restart ist Docker Standard, auf unhealthy kannst du selber reagieren und neu starten lasesen. Abhängig von deinem Setup.

https://forum.fhem.de/index.php/topic,89745.msg1261205.html#msg1261205

GammaTwin

Ich probiere autoheal. Das meinte ich mit Workaroud, Sofortmaßnahme wäre das bessere Wort.

Mal schauen, ob ich die Fehlerursache noch finde.