DSMR-Reader losing conenction to datalogger since last update (:latest)

[Mister86NL]

Support guidelines

• [X] I've read the support guidelines

I've found an issue and checked that ...

• [X] ... the documentation does not mention anything about my problem
• [X] ... there are no open or closed issues that are related to my problem

Description

Since the last update of the docker container yesterday the connection between DSMR-reader and the datalogger (base on ESP) is unstable:

No recent readings received (an hour ago)

After restarting the docker container, it is stable for some time. It occurs 3 times now since yesterday, running DSMR-Reader since Aug 2020, never saw this behavior again.

Also, the datalogger (ESP) is stable and reachable on both HTTP and TELNET when this error occurs.

Expected behaviour

Stable connection, as the last ~3 years :)

Actual behaviour

DSMR-Reader gives en error on the 'About' Page and via Pushover API:

No recent readings received (an hour ago)

Steps to reproduce

none.

Docker info

1337@UnraidSERVER:~# docker info
Client:
 Version:    24.0.9
 Context:    default
 Debug Mode: false

Server:
 Containers: 30
  Running: 29
  Paused: 0
  Stopped: 1
 Images: 25
 Server Version: 24.0.9
 Storage Driver: btrfs
  Btrfs: 
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 7c3aca7a610df76212171d200ca3811ff6096eb8
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.74-Unraid
 Operating System: Slackware 15.0 x86_64 (post 15.0 -current)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.54GiB
 Name: UnraidSERVER
 ID: e87DD754-643f-443f-b092-2823ef62bca3
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

WARNING: No swap limit support

Version

1337@UnraidSERVER:~# uname -a Linux UnraidSERVER 6.1.74-Unraid #1 SMP PREEMPT_DYNAMIC Fri Feb 2 11:06:32 PST 2024 x86_64 Intel(R) Pentium(R) Gold G5400 CPU @ 3.70GHz GenuineIntel GNU/Linux

Docker compose

n/a, using Unraid

Container logs

127.0.0.1 - - [16/Apr/2024:19:40:58 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:41:13 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:41:28 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:41:43 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:41:59 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:42:14 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:42:29 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:42:45 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:43:00 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:43:15 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:43:31 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:43:46 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:44:01 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:44:16 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:44:32 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:44:47 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-" 127.0.0.1 - - [16/Apr/2024:19:45:02 +0200] "GET /about HTTP/1.1" 200 13437 "-" "curl/8.5.0" "-"

Additional info

Please tell me how to provide some more logs, container logs are the wrong level, maybe on the admin pages?

Debug info:

DSMR-READER App | Python | Database v5.11 | v3.11.9 | postgresql BE sleep | DL sleep | Retention | Override 1.0s | 3.0s | 2232h | False Latest telegram version read | Parser settings "50" | "4"

DATA Telegrams total (est.) 1843579 Consumption records electricity | gas (est.) 192844 | 85853

POSTGRESQL SIZE OF LARGEST TABLES (> 500 MB) public.dsmr_datalogger_dsmrreading 761 MB

[xirixiz]

Hmm, wat vreemd. Je bent eigenlijk de enige die een issue meldt. Zou je voor de zekerheid even terug willen gaan naar de vorige image. Dat heeft geen impact op DSMR zelf, alleen de onderliggende techniek (s6-overlay v2 vs v3) is veranderd. Het zou ermee te maken kunnen hebben, maar door het op deze manier te testen weten we het zeker of het aan de image ligt.

Dit is de vorige image.

ghcr.io/xirixiz/dsmr-reader-docker:5.11.0-2024.02.04

[Mister86NL]

He,

Ik heb nu versie 5.11.0-2024.02.04 draaien, kijk even aan of het stabiel is, to be continued.

[erwindouna]

Ik moet helaas ook melden dat de verbinding instabiel lijkt. Ik heb gisteren geüpdatet en draai deze via de HomeAssistant Add-on. Bij een herstart lijkt de verbinding stabiel en na een x aantal minuten valt de verbinding weg.

[sanderdw]

Vreemd, ik heb hier één instance (met de addon) die gewoon goed draait sinds de upgrade. @erwindouna en @Mister86NL welke hardware arch draaien jullie?

[erwindouna]

Vreemd, ik heb hier één instance (met de addon) die gewoon goed draait sinds de upgrade. @erwindouna en @Mister86NL welke hardware arch draaien jullie?

Ik draai Home Assistant via een Intel NUC, en dan middels Proxmox.

[BebeMischa]

Alleen for referentie - hier HAOS op x86 intel machine, geen virtual's, alles up to date, draait prima.

[erwindouna]

Ik start nu om de 10 minuten de Add-on op. Het lijkt er dus op dat de USB steeds wegvalt. Hierna stopt DSMR Reader met het kunnen uitlezen van de datalogger. Consistent lijkt na x minuten de volgende error te komen:

  File "/app/dsmr_backend/mixins.py", line 96, in run_once
    self.run(data=self.data, **options)
  File "/app/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 29, in run
    telegram = next(self.telegram_generator)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 57, in read_telegram
    incoming_bytes = serial_handle.read(MAX_BYTES_PER_READ)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/serial/serialposix.py", line 595, in read
    raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)```

[Alfagek]

Heel vreemd, hier ook de addon van @sanderdw draaien. En zelfs op 3 verschillende locaties. En alles draait hier gewoon prima.

2x proxmox met HA in VM met usb p1 1x proxmox met HA in VM met telnet P1

[erwindouna]

Bij het downgrade van de add-on, door Sander, lijkt bij mij het probleem opgelost te zijn. De data logger lijkt nog steeds te crashen, alleen herstart hij zichzelf heel goed. Nog steeds niet ideal, alleen voor nu wel 'stabiel' genoeg.

[erwindouna]

Heel vreemd, hier ook de addon van @sanderdw draaien. En zelfs op 3 verschillende locaties. En alles draait hier gewoon prima.

2x proxmox met HA in VM met usb p1 1x proxmox met HA in VM met telnet P1

Als je de logging bekijkt, zie je dan ook de SerialException error toevallig voorbij komen?

[Alfagek]

Heel vreemd, hier ook de addon van @sanderdw draaien. En zelfs op 3 verschillende locaties. En alles draait hier gewoon prima. 2x proxmox met HA in VM met usb p1 1x proxmox met HA in VM met telnet P1

Als je de logging bekijkt, zie je dan ook de SerialException error toevallig voorbij komen?

Nee, geen error. Had van de week al de versie getest en toen ging ook alles goed met mijn eigen systeem. En vannacht ge-update met originele versie. En vanmiddag de andere 2 ge-update op afstand. En zowel de HA log als DSMR addon, geen fout meldingen te zien

[erwindouna]

Lees je de slimme meter uit via een seriële poort of IP adres?

[Alfagek]

Lees je de slimme meter uit via een seriële poort of IP adres?

Stond erbij ;-). 2x usb. Dus serial (incl eigen) en 1x via ip (telnet dus)

en HA versie 2024.4.3 en postgress 16.2

[erwindouna]

Lees je de slimme meter uit via een seriële poort of IP adres?

Stond erbij ;-). 2x usb. Dus serial (incl eigen) en 1x via ip (telnet dus)

Check. Hoe heb je deze in Proxmox gebind en in de add-on? Wellicht ligt daar de oorzaak voor het crashen. Frappante is wel dat DSMR data logger zichzelf goed herstart in de zojuist gepubliceerde versie.

[Alfagek]

USB word geforward in de 2 systemen. En gebruik altijd usb naam ipv usb nummer. Dus dev by id ipv dev bij serial in de addon.

En je draait ook op de recente HA versie en postgress?

[erwindouna]

Ja, en daarin lijkt onze setup hetzelfde. Ik zal morgen eens wat proberen te debuggen in een Docker container. Bedankt voor het beantwoorden en delen van inzicht!

[xirixiz]

Zowel Sander als ik zijn overgesptapt van s6-overlay v2 naar overlay v3. Mijn gevoel is dat de verbinding altijd al instabiel was aan jouw kant (no offense :)), maar dat de "oude" images met s6-overlay v2 een beter herstelmechanisme hadden. Ik ga nog even in de documentatie duiken, misschien kom ik nog iets tegen.

Verder zag ik inderdaad dat de logs van DSMR zelf wat lastig te verkrijgen zijn, ik ga een aantal zaken aanpassen zodat er wat betere logging is, maar dat terzijde.

[xirixiz]

Mogelijk een foutje ontdket 😄

Services voor S6-overlay moeten de waarde longrun hebben als type, maar staat voor de datalogger geconfigureerd als oneshot

https://github.com/xirixiz/dsmr-reader-docker/blob/main/rootfs/etc/s6-overlay/s6-rc.d/svc-dsmr-datalogger/type

Ik denk dat jullie verbinding al onstabiel was, maar dat de Docker image vergevingsgezind was. Ik ben een nieuwe development tag aan het maken zodat we daarmee even kunnen testen, maar dat vereist volges mij ook wat werk voor @sanderdw.

@sanderdw mogelijk kunnen we eens kijken of we het samen wat beter kunnen strucureren. We kunnen daarbij ook Dennis eventueel betrekken, ik weet dat hij daar ook weleens over heeft nagedacht.

[sanderdw]

Ik vermoed ook dat het bij hun al instabiel was: https://github.com/sanderdw/hassio-addons/issues/86#issuecomment-2062379258

En de one-shot configuratie zou dat dan wel bevestigen.

Wat mij betreft maken we eerst een release met die aanpassing. Daarna kunnen we prima nadenken over herstructurering 👍.

[erwindouna]

Ik heb vannacht de logging goed laten opslaan en inderdaad, de seriële verbinding is instabiel. Dit was waarschijnlijk al zo en werd door de oneshot aanpassing voor mij in ieder geval pijnlijk duidelijk. Ik zal vandaag dit eens in een aparte Docker container verder proberen te debuggen. Wel is het fijn om te lezen dat, ondanks instabielgedrag, de containers zich weer goed herstellen. Er is een 'oplossing', nu de oorzaak nog vinden die volgens mijn observatie buiten de Add-on en DSMR Reader Docker ligt.

Wel hartelijk dank voor jullie ondersteuning en hulp in deze situatie; dat wordt zeer gewaardeerd! 👍

[sanderdw]

He,

Ik heb nu versie 5.11.0-2024.02.04 draaien, kijk even aan of het stabiel is, to be continued.

Jij nog een update @Mister86NL?

[Mister86NL]

Ik gebruik dus een datalogger op basis van IP (Telnet). En sinds de 'downgrade' naar versie 5.11.0-2024.02.04 heb ik nog geen dataverlies gehad en lopen de waardes gewoon live mee, zoals altijd eigenlijk.

Vraag is naar mijn idee hoe ik wat (meer) info kan aanreiken als ik de docker container weer naar 'latest' breng en het euvel zich weer voordoet.

[sanderdw]

De vraag is of het bij jou ook niet gewoon al instabiel was. Je zou toch iets in de logs moeten zien wanneer het niet meer lukt om metingen te verwerken?

[Mister86NL]

Ik heb even verder in de container logs gekeken en kom niet meer tegen dan deze meldingen tussen 14:00 en 23:30, er zijn wel meer meldingen maar die zijn identiek aan onderstaande meldingen. let op, dit is na downgrade naar versie 5.11.0-2024.02.04 waarbij er geen melding in 'about' danwel Pushover komt dat de datalogger al een uur 'offline' is.

[2024-04-17 14:44:52 +0200] [7556] [INFO] Autorestarting worker after current request. [2024-04-17 14:44:52 +0200] [7556] [INFO] Worker exiting (pid: 7556) [2024-04-17 14:44:53 +0200] [8540] [INFO] Booting worker with pid: 8540 [2024-04-17 15:32:31 +0200] [8540] [INFO] Autorestarting worker after current request. [2024-04-17 15:32:31 +0200] [8540] [INFO] Worker exiting (pid: 8540) [2024-04-17 15:32:31 +0200] [9857] [INFO] Booting worker with pid: 9857 [2024-04-17 16:24:16 +0200] [9857] [INFO] Autorestarting worker after current request. [2024-04-17 16:24:16 +0200] [9857] [INFO] Worker exiting (pid: 9857) [2024-04-17 16:24:16 +0200] [11283] [INFO] Booting worker with pid: 11283 [2024-04-17 18:31:44 +0200] [11283] [INFO] Autorestarting worker after current request. [2024-04-17 18:31:44 +0200] [11283] [INFO] Worker exiting (pid: 11283) [2024-04-17 18:31:44 +0200] [14804] [INFO] Booting worker with pid: 14804 [2024-04-17 20:26:31 +0200] [14804] [INFO] Autorestarting worker after current request. [2024-04-17 20:26:31 +0200] [14804] [INFO] Worker exiting (pid: 14804) [2024-04-17 20:26:31 +0200] [17974] [INFO] Booting worker with pid: 17974 2024-04-17 20:54:24,905 ERROR mixins run_once 107 | dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last): File "/app/dsmr_backend/mixins.py", line 96, in run_once self.run(data=self.data, **options) File "/app/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 29, in run telegram = next(self.telegram_generator) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 51, in read_telegram raise RuntimeError( RuntimeError: It took too long to detect a telegram. Check connection params. Bytes currently in buffer: 107

2024-04-17 21:14:00,102 ERROR mixins run_once 107 | dsmr_datalogger.management.commands.dsmr_datalogger: [!] Exception raised. Traceback (most recent call last): File "/app/dsmr_backend/mixins.py", line 96, in run_once self.run(data=self.data, **options) File "/app/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 29, in run telegram = next(self.telegram_generator) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/dsmr_datalogger/scripts/dsmr_datalogger_api_client.py", line 51, in read_telegram raise RuntimeError( RuntimeError: It took too long to detect a telegram. Check connection params. Bytes currently in buffer: 984

[2024-04-17 22:02:21 +0200] [17974] [INFO] Autorestarting worker after current request. [2024-04-17 22:02:21 +0200] [17974] [INFO] Worker exiting (pid: 17974) [2024-04-17 22:02:22 +0200] [20626] [INFO] Booting worker with pid: 20626 [2024-04-17 23:21:07 +0200] [20626] [INFO] Autorestarting worker after current request. [2024-04-17 23:21:08 +0200] [20626] [INFO] Worker exiting (pid: 20626)

[xirixiz]

Could you try this tag? I've made some modifications.

ghcr.io/xirixiz/dsmr-reader-docker:development

Maybe @sanderdw need to make some modifications. Not sure.

[Mister86NL]

Sure, al heb ik sinds dat ik draai met 5.11.0-2024.02.04 geen problemen meer ervaren (lees: geen meldingen van >60min datalogger timeout). Ik zal hem even omkatten naar :dev

[sanderdw]

Could you try this tag? I've made some modifications.

ghcr.io/xirixiz/dsmr-reader-docker:development

Maybe @sanderdw need to make some modifications. Not sure.

dsmr-reader-docker:development is working

[xirixiz]

Sure, al heb ik sinds dat ik draai met 5.11.0-2024.02.04 geen problemen meer ervaren (lees: geen meldingen van >60min datalogger timeout). Ik zal hem even omkatten naar :dev

Kk, goed om te horen. De bug die erin zat voor de datalogger moest er sowieso uit. Werkt het nog naar behoren? Zo ja, dan maak ik een nieuwe "latest" release vandaag.

[gschot]

Top te zien dat dit inmiddels loopt. Ik monitor een DSMR meter elders over een VPN, welke af en toe wegvalt. Als de VPN terugkomt, herstelde de verbinding naar de meter ook niet automatisch meer. Ik heb hierin geprobeerd parameters in de settings van DSMR reader te wijzigen, hopende op een reconnect, maar ik moest hierop echt de container opnieuw starten. Nu tijdelijk teruggerold naar 20240204, welke wel de verbinding automatisch weer oppakt na verbreken. Ik wacht toch even voor de zekerheid een nieuwe latest af. Maar hulde voor het snelle oppakken, ik wilde deze net melden anders.

[Mister86NL]

Sure, al heb ik sinds dat ik draai met 5.11.0-2024.02.04 geen problemen meer ervaren (lees: geen meldingen van >60min datalogger timeout). Ik zal hem even omkatten naar :dev

Kk, goed om te horen. De bug die erin zat voor de datalogger moest er sowieso uit. Werkt het nog naar behoren? Zo ja, dan maak ik een nieuwe "latest" release vandaag.

Tot op heden geen meldingen gehad met de development release nee :)

[xirixiz]

Build loopt voor een nieuwe latest (2024.04.02). https://github.com/xirixiz/dsmr-reader-docker/actions/runs/8750884377

[xirixiz]

New latest available: https://github.com/xirixiz/dsmr-reader-docker/pkgs/container/dsmr-reader-docker

[gschot]

I just tested with 2024.04.02. When I force to restart the VPN over which data is collected, 2024.04.02 recovers the connection correctly after the VPN is back up. So for me this version fixed the issue in 2024.04.01. Thanks for the quick fix!

[sanderdw]

Ik zie hier iets fout gaan, al komt de UI wel up:

[xirixiz]

....ik dacht het te weten, maar eigenlijk zie ik niets verkeerd staan.

Ik zie dat er eerst een fout opduikt, maar dat het daarna wel goed gaat

Listening at: unix.....etc

Het lijkt dus op een dependency issue, maar kan verder geen kwaad. Fix ik morgen denk ik even.

[xirixiz]

Kk, nieuwe development tag gemaakt weer @sanderdw . Hopelijk de laatste keer nu 😄

[sanderdw]

Same?

[ INFO ] ENABLE_CLIENTCERT_AUTH is disabled, nothing to see here. Continuing...
[ INFO ] Checking for NGINX SSL configuration...
[ INFO ] ENABLE_NGINX_SSL is disabled, nothing to see here. Continuing...
[ INFO ] Checking for HTTP AUTHENTICATION configuration...
[ INFO ] ENABLE_HTTP_AUTH is disabled, nothing to see here. Continuing...
[ INFO ] Configuring DSMR Reader to run without the datalogger process. A remote datalogger (api_client) is required...
[ INFO ] Adding DSMRREADER_REMOTE_DATALOGGER_SLEEP to the DSMR Reader remote datalogger configuration...
[ INFO ] Adding DSMRREADER_LOGLEVEL to the DSMR Reader configuration...
s6-rc: info: service init-docker-entrypoint successfully started
s6-rc: info: service svc-dsmr-remote-datalogger: starting
s6-rc: info: service svc-dsmr-datalogger: starting
s6-rc: info: service svc-dsmr-backend: starting
s6-rc: info: service svc-dsmr-remote-datalogger successfully started
s6-rc: info: service svc-dsmr-backend successfully started
s6-rc: info: service svc-dsmr-backend-log: starting
s6-rc: info: service svc-dsmr-datalogger successfully started
s6-rc: info: service svc-dsmr-datalogger-log: starting
s6-rc: info: service svc-dsmr-backend-log successfully started
s6-rc: info: service svc-dsmr-webinterface: starting
s6-rc: info: service svc-dsmr-datalogger-log successfully started
s6-rc: info: service svc-dsmr-webinterface successfully started
s6-rc: info: service svc-nginx: starting
s6-rc: info: service svc-dsmr-webinterface-log: starting
s6-rc: info: service svc-nginx successfully started
s6-rc: info: service svc-dsmr-webinterface-log successfully started
s6-rc: info: service legacy-services: starting
Starting DSMR Reader - webinterface...
Starting DSMR Reader - nginx...
Starting DSMR Reader - backend...
s6-rc: info: service legacy-services successfully started
2024/04/20 09:09:26 [crit] 343#343: *1 connect() to unix:///tmp/gunicorn--dsmr_webinterface.socket failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: _, request: "GET /about HTTP/1.1", upstream: "http://unix:///tmp/gunicorn--dsmr_webinterface.socket:/about", host: "127.0.0.1"
127.0.0.1 - - [20/Apr/2024:09:09:26 +0200] "GET /about HTTP/1.1" 502 150 "-" "curl/8.5.0" "-"
[2024-04-20 09:09:26 +0200] [325] [INFO] Starting gunicorn 20.1.0
[2024-04-20 09:09:26 +0200] [325] [INFO] Listening at: unix:/tmp/gunicorn--dsmr_webinterface.socket (325)
[2024-04-20 09:09:26 +0200] [325] [INFO] Using worker: sync
[2024-04-20 09:09:26 +0200] [357] [INFO] Booting worker with pid: 357
Current logging level set to "ERROR". More information can be found here: https://dsmr-reader.readthedocs.io/en/latest/how-to/troubleshooting/enabling-debug-logging.html
127.0.0.1 - - [20/Apr/2024:09:09:42 +0200] "GET /about HTTP/1.1" 200 16104 "-" "curl/8.5.0" "-"
127.0.0.1 - - [20/Apr/2024:09:09:57 +0200] "GET /about HTTP/1.1" 200 16104 "-" "curl/8.5.0" "-"

[xirixiz]

@dennissiemensma ivm unix:///tmp/gunicorn--dsmr_webinterface.socket, moet de webinterface eerst gestart zijn, of eerst nginx? Ik ben de volgorde even kwijt :)

Eerst de webservice om de socket te maken, en daarna moet nginx ermee connecten toch?

[xirixiz]

Ik heb er even een check ingebouwd of de socket bestaat, dat lijkt te werken, maar zoals eerder gezegd kan ik dat helaas zelf niet testen. De nieuwe development release wordt gebouwd @sanderdw

15 min ongeveer: https://github.com/xirixiz/dsmr-reader-docker/actions/runs/8763798180

[dennissiemensma]

@dennissiemensma ivm unix:///tmp/gunicorn--dsmr_webinterface.socket, moet de webinterface eerst gestart zijn, of eerst nginx? Ik ben de volgorde even kwijt :)

Eerst de webservice om de socket te maken, en daarna moet nginx ermee connecten toch?

Ik denk eerst de app (webinterface), omdat die niet afweet van Nginx, maar andersom wel.

[sanderdw]

Ziet er goed uit nu

[xirixiz]

Mooi, de laatste latest is ook released 👍🏻

[xirixiz]

Confirmation was er al gegeven dat het issue is verholpen, en nu met het laatste issue er ook uit denk ik dat de image weer helemaal op orde is. Die kan er weer een aantal jaren tegenaan zonder grote updates wss 😄 . Bedankt allemaal voor jullie input en hulp!

[Mister86NL]

Zojuist branch weer op :latest gezet. We gaan het meemaken :-)

[gschot]

Hoewel inmiddels gesloten, kreeg ik vanochtend een melding dat er wat was misgegaan. Uiteindelijk bleek dat de dsmr container was herstart, na de volgende melding:

2024/04/23 06:14:42 [error] 181#181: *52391 upstream timed out (110: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /about HTTP/1.1", upstream: "http://unix:///tmp/gunicorn--dsmr_webinterface.socket/about", host: "127.0.0.1"
127.0.0.1 - - [23/Apr/2024:06:14:42 +0200] "GET /about HTTP/1.1" 504 160 "-" "curl/8.5.0" "-"
[2024-04-23 06:14:42 +0200] [113] [CRITICAL] WORKER TIMEOUT (pid:23308)
[2024-04-23 06:14:43 +0200] [113] [WARNING] Worker with pid 23308 was terminated due to signal 9
[2024-04-23 06:14:43 +0200] [25925] [INFO] Booting worker with pid: 25925
...
...
2024/04/23 06:16:32 [error] 181#181: *52415 upstream timed out (110: Operation timed out) while reading response header from upstream, client: 127.0.0.1, server: _, request: "GET /about HTTP/1.1", upstream: "http://unix:///tmp/gunicorn--dsmr_webinterface.socket/about", host: "127.0.0.1"
127.0.0.1 - - [23/Apr/2024:06:16:32 +0200] "GET /about HTTP/1.1" 504 160 "-" "curl/8.5.0" "-"
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service svc-nginx: stopping
s6-rc: info: service svc-dsmr-webinterface-log: stopping
s6-rc: info: service svc-dsmr-remote-datalogger: stopping
s6-rc: info: service svc-dsmr-datalogger-log: stopping
s6-rc: info: service svc-dsmr-backend-log: stopping
s6-rc: info: service svc-dsmr-webinterface-log successfully stopped
s6-rc: info: service svc-dsmr-datalogger-log successfully stopped
s6-rc: info: service svc-dsmr-datalogger: stopping
s6-rc: info: service svc-dsmr-backend-log successfully stopped
s6-rc: info: service svc-dsmr-backend: stopping
s6-rc: info: service svc-nginx successfully stopped
s6-rc: info: service svc-dsmr-webinterface: stopping
s6-rc: info: service svc-dsmr-remote-datalogger successfully stopped
s6-rc: info: service svc-dsmr-datalogger successfully stopped
s6-rc: info: service svc-dsmr-backend successfully stopped
s6-rc: info: service svc-dsmr-webinterface successfully stopped
s6-rc: info: service init-docker-entrypoint: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service init-docker-entrypoint successfully stopped
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
[2024-04-23 06:16:34 +0200] [113] [INFO] Handling signal: term

Ik heb nog een backup dsmr reader draaien om data te blijven loggen, deze was niet gecrashed. Het verschil was dat ik bij de gecrashte instance nog een browser op mijn laptop open had staan die /live pagina open had.

De container is herstart en de datacollectie liep daarna wel weer door.

Versie is: 2024.04.03

[xirixiz]

@gschot Kan je wellicht een nieuw issue aanmaken, dit is niet gerelateerd aan dit topic namelijk :). Ik ga er vandaag even naar kijken.

[gschot]

Ik zal een nieuwe aanmaken als ik het kan reproduceren. Ik had m hier onder geplaatst omdat ik meende dat het 'restpuntje' van dit issue ook gerelateerd was aan die upstream connection.

EDIT: Ik zal 'm eerst proberen te reproduceren.

[xirixiz]

Ja is ook geen probleem hoor, maar de oorzaak ligt niet in lijn.... weet ik nu al 😄 Vandaar.