Influx does not always start after reboot of docker container🚨

[Rudios81]

Description

I am running dsmrreader as a docker container on my Raspberry PI 4. Alongside the dsmrreader container some other containers are running, including influxdb. The problem I'm facing is that when my PI is rebooted, or dockers are updated and restarted the influx export function of dsmrreader does not work anymore, but the only thing I have to do to fix it is to disable and re-enable the influxdb integration

DSMR-reader version

5.10.3

DSMR-reader platform

Docker

Debug info dump

DSMR-READER
    App / Python / Database                                                    v5.10.3 / v3.11.1 / postgresql
    BE sleep / DL sleep / Retention / Override                                     1.0s / 5.0s / 672h / False
    Latest telegram version read / Parser settings                                                 "50" / "4"

DATA
    Telegrams total (est.)                                                                             114767
    Consumption records electricity / gas (est.)                                                 20887 / 4529

[dennissiemensma]

Thanks for reporting. You will have to check the logs first to see what is causing this, as it could be simply a boot order issue. Are there any errors?

[Rudios81]

I have checked the logs by putting the log variable to DEBUG for my docker environment but there is nothing notified regarding influxdb.

If all is running fine and I then stop the influxdb container, I do see error messages telling it can't connect and when the influxdb container is started again, these error messages stop showing and data is pushed into my influxdb again.

Now, after a reboot there is no data flowing into my influxdb, and if in that situation the influxdb container is stopped, there is not error message telling me that it can't connect to influxdb, while I would expect these messages based on my findings above.

An additional test I did is not disable/re-enable the influxdb integration as a whole, but change 1 single parameter on the config page, and hit save. That also does restore the communication to my influxdb container.

Now I know this is a very blunt and harsh conclusion but it looks like the influxdb integration enabled setting is somehow ignored during startup of the dsmrreader container.

[dennissiemensma]

What is your docker compose file of DSMR-reader? Without the secrets or passwords

[Rudios81]

dsmr: image: xirixiz/dsmr-reader-docker:latest depends_on: dsmrdb: condition: service_healthy container_name: dsmr links:

• dsmrdb cap_add:
• NET_ADMIN restart: always networks:
• $TRAEFIK_PROXY_NET volumes:
• /etc/localtime:/etc/localtime:ro
• $DOCKER_DIR/dsmr/backups:/app/backups environment:
• TZ=$SYSTEM_TIME_ZONE
• DJANGO_TIME_ZONE=Europe/Amsterdam
• VIRTUAL_HOST=localhost

  - DSMRREADER_LOGLEVEL=DEBUG

  ports:

  - 7777:80

  - 7779:443

  devices:

• /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AR54KX6T-if00-port0:/dev/ttyUSB0

  - "/dev/ttyUSB1:/dev/ttyUSB0"

  healthcheck:

  disable: true

  healthcheck: test: [ "CMD", "curl", "-Lsf", "http://127.0.0.1/about", "-o", "/dev/null", "-w", "HTTP_%{http_code}" ] interval: 10s timeout: 5s retries: 10

And I'm using Traefik to connect to the container, therefor network ports are not exposed.

[dennissiemensma]

You can try adding the influxdb service to the "depends_on" of DSMR-reader and see if that makes any difference. If influxdb or any other service takes too long to boot, DSMR-reader cannot distinguish whether it's available soon or never will be at all, and will have to continue. I can add some delay, but that will be very limited. Therefore preventing this can happen at all by boot order is usually an easier fix.

[dennissiemensma]

@Rudios81 any progress in debugging?

[Rudios81]

I have tested with the dependency of my influx container, but it looks it has no impact. First I only added my influxdb on the 'links' declaration of my docker config, but no difference. Then I added my influxdb container to the 'depends_on' declaration for dsmrreader container and also added a 'service-healthy' condition but still no change. When all my docker containers are restarted (eg. complete RPi reboot or docker service stop/start) there is no data flowing into my influxdb. To restart this data flow I only have to hit the 'save' button on the influx configuration pages of dsmrreader. Can even be without a change, hitting 'save' is enough.

[dennissiemensma]

It has been a while. Did you also try (manually) restarting the entire DSMR-reader container after everything is up?

Saving the influxdb configuration will cause the backend proces of DSMR-reader to restart in the background. It is not meant for restoring the connection, but to ensure any changes to the connection parameters are forced on reconnect. That it also happens to "fix" the issue as well, is merely a side-effect.

[Rudios81]

If only the DSMR-reader container is restarted all is fine, influxdb data flow is restored without needed actions.

[dennissiemensma]

Thanks for checking. Then I think you may want to delay starting (or restart) DSMR-reader on boot or restart it after updating containers. other containers should run before DSMR-reader does.