Container stoppt bei Verbindungsproblemen
Closed this issue · 8 comments
Hallo zusammen,
meine Soletrus Installation läuft nun seit 3 Wochen auf einem Proxmox Server unter Alpine Cobtainer.
Seit 2 Tagen werden aber Daten auf einmal nicht mehr geliefert. Die Weboberfläche funktioniert, aber keine Inhalte.
Wenn ich mit "docker compose up -d" wieder starte ist die Verbindung wieder da.
Rückmeldung des Starts:
[+] Running 0/1
⠙ Network solectrus_default Creating 0.1s
WARN[0000] Found orphan containers ([solectrus-senec-collector-1]) for this project. If you rem[+] Running 7/8 this service in your compose file, you can run this command with the --remove-o ⠹ Network solectrus_default Created 36.1s
✔ Container solectrus-redis-1 Healthy 13.4s
✔ Container solectrus-watchtower-1 Starte... 3.3s
✔ Container solectrus-influxdb-1 Healthy 33.9s
✔ Container solectrus-db-1 Healthy 13.4s
✔ Container solectrus-app-1 Started 35.7s
✔ Container solectrus-mqtt-collector-1 St... 35.7s
✔ Container solectrus-forecast-collector-1 Started 35.3s
Wenn ich das Log bis zum Datenabruch ansehe:
mqtt-collector-1 | 2024-03-17 18:17:22 +0000 {"house_power"=>392}
mqtt-collector-1 | #<Thread:0x0000718896ce1e50 /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/client.rb:276 run> terminated with exception (report_on_exception is true):
mqtt-collector-1 | /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/packet.rb:222:in `getbyte': Connection reset by peer @ io_fillbuf - fd:5 (Errno::ECONNRESET)
mqtt-collector-1 | from /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/packet.rb:222:in `read_byte'
mqtt-collector-1 | from /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/packet.rb:30:in `read'
mqtt-collector-1 | from /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/client.rb:471:in `receive_packet'
mqtt-collector-1 | from /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/client.rb:278:in `block in connect'
Offenbar ist der MQTT-Broker kurzzeitig nicht erreichbar gewesen. Idealerweise sollte der MQTT-Collector bei unerwarteten Abbrüchen automatisch neu gestartet wird. Das erreicht man über die restart-Option in der docker-compose.yml, wo entweder always oder unless-stopped eingetragen werden sollte, z.B. so:
restart: unless-stopped
Außerdem auffällig ist die Warnung zum verwaisten SENEC-Collector. Hattest du den Service früher mal, aber dann in der docker-compose.yml entfernt? Das hier könnte helfen:
docker system prune
Ich habe in der Datei docker-compose.yml diesen Eintrag mit restart: unless-stopped angepasst
mqtt-collector:
image: ghcr.io/solectrus/mqtt-collector:latest
labels:
- 'com.centurylinklabs.watchtower.scope=solectrus'
depends_on:
influxdb:
condition: service_healthy
links:
- influxdb
environment:
- INFLUX_HOST
- INFLUX_SCHEMA
- INFLUX_PORT
- INFLUX_TOKEN=${INFLUX_TOKEN_WRITE}
- INFLUX_ORG
- INFLUX_BUCKET
- INFLUX_MEASUREMENT=${INFLUX_MEASUREMENT_PV}
- MQTT_HOST
- MQTT_PORT
- MQTT_SSL
- MQTT_USERNAME
- MQTT_PASSWORD
- MQTT_TOPIC_HOUSE_POW
- MQTT_TOPIC_GRID_POW
- MQTT_TOPIC_BAT_CHARGE_CURRENT
- MQTT_TOPIC_BAT_FUEL_CHARGE
- MQTT_TOPIC_BAT_POWER
- MQTT_TOPIC_BAT_VOLTAGE
- MQTT_TOPIC_CASE_TEMP
- MQTT_TOPIC_CURRENT_STATE
- MQTT_TOPIC_MPP1_POWER
- MQTT_TOPIC_MPP2_POWER
- MQTT_TOPIC_MPP3_POWER
- MQTT_TOPIC_INVERTER_POWER
- MQTT_TOPIC_WALLBOX_CHARGE_POWER
- MQTT_FLIP_BAT_POWER
restart: unless-stopped
logging:
options:
max-size: '10m'
max-file: '3'
Letzter Eintrag im Log bevor nicht mehr in der Oberfläche dargestellt wurde:
mqtt-collector-1 | #<Thread:0x00007fd3f6781640 /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/client.rb:276 run> terminated with exception (report_on_exception is true):
mqtt-collector-1 | /usr/local/bundle/gems/mqtt-0.6.0/lib/mqtt/packet.rb:222:in `getbyte': Connection reset by peer @ io_fillbuf - fd:5 (Errno::ECONNRESET)
Wenn ich dich richtig verstehe, hast du in der docker-compose.yml den Eintrag für restart ergänzt, weil er vorher nicht da war. Hast du danach auch neu gestartet? Ohne ein docker compose up -d wird die Änderung nicht übernommen.
Die Fehlermeldung zeigt, dass es wohl Verbindungsprobleme mit dem MQTT-Broker gab. Der MQTT-Collector hat sich dann beendet, was dann dazu führte, dass SOLECTRUS keine Daten mehr bekam. Wichtig ist, dass der MQTT-Collector dauerhaft läuft. Wenn das nicht der Fall ist, können auch keine Daten angezeigt werden. Ob und welche Container laufen, lässt sich mit docker compose ps herausfinden.
Der Eintrag
restart: unless-stopped
Stand vorher auf always
Ich hatte dich so verstanden, dass ich diesen auf unless-stopped stellen soll
War das nun falsch?
Was ich beim durchforsten der Logs noch festgestellt hatte, mir wurde aufgezeigt zu wenig Speicher zu haben.
Habe nun den Seicher von 512 MB auf 2GB geschraubt.
Habe auch mal meinen MQTT Broker ein update verpasst und diesen neu gestartet.
Dessen Logs waren aber eigentlich ok.
Mal schauen wann Solectrus wieder Schluckauf bekommt, weil keine Verbidung zum MQTT Broker hat.
Ob unless-stopped oder always - das macht keinen großen Unterschied. Hauptsache, es gibt überhaupt einen restart.
Zuwenig Speicher? Wo wird das angezeigt? Der RAM-Verbrauch des Collector-Containers sollte unter 50 MB liegen. Oder meinst du die Log-Größe? Die lassen sich begrenzen.
docker compose logs
War das eingetragen:
redis-1 | 1:C 20 Mar 2024 04:43:54.545 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see jemalloc/jemalloc#1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
Seite heute in der Früh keinen Schluckauf mehr.
Entweder weil ich den Mqtt-Broker aktualisiert habe und neu gestartet wurde oder weil ich den Speicher im LXC Container hochgeschraubt habe,
Die Warnung von Redis ist keine Beschwerde über zu wenig Speicher, sondern nur ein Hinweis, dass es Probleme geben könnte, wenn u.a. der Speicher knapp wird. Man kann den Docker-Host konfigurieren, um das abzustellen, das ist aber nicht zwingend. Auch hat Redis gar nichts mit dem MQTT-Collector zu tun, sondern sorgt nur für das Caching im Dashboard.
Was mir weiterhin nicht ganz klar ist, ob der Container aufgrund irgendeines Fehlers beendet wurde und nicht neu gestartet wurde (trotz restart-Option) oder ob der MQTT-Collector anderweitig Probleme hatte, der Container aber weiter lief.
Wie dem auch sei, ich arbeite gerade am MQTT-Collector und mache ihn robuster gegenüber Ausfälle.
Ja dann freue ich mich schon auf den robusten MQTT-Collector