starred/ddns-updater
1
0
Fork 0
mirror of https://github.com/qdm12/ddns-updater.git synced 2026-08-02 18:48:49 -04:00
Code Issues 312 Packages Projects Releases 10 Wiki Activity

Traefik labels not picked up when set in DDNS-updater container #256

New Issue
Closed
opened 2025-11-20 04:22:04 -05:00 by saavagebueno · 13 comments
saavagebueno commented 2025-11-20 04:22:04 -05:00
Owner
Copy Link

Originally created by @Plaenkler on GitHub (Feb 12, 2023).

After starting the container everything behaves normally. As soon as the web server is accessed there is HTTP 404 and the status of the container changes to unhealthy. There is nothing to see in the log.

Compose:

  ddns-updater:
    image: qmcgaw/ddns-updater
    container_name: ddns
    restart: always
    security_opt:
      - no-new-privileges:true
    environment:
      - PERIOD=1m
      - UPDATE_COOLDOWN_PERIOD=5m
      - PUBLICIP_FETCHERS=all
      - PUBLICIP_HTTP_PROVIDERS=all
      - PUBLICIPV4_HTTP_PROVIDERS=all
      - PUBLICIPV6_HTTP_PROVIDERS=all
      - PUBLICIP_DNS_PROVIDERS=all
      - PUBLICIP_DNS_TIMEOUT=3s
      - HTTP_TIMEOUT=10s
      # Web GUI
      - LISTENING_PORT=10000
      - ROOT_URL=/
      # Backup
      - BACKUP_PERIOD=0 # 0 to disable
      - BACKUP_DIRECTORY=/updater/data
      # Other
      - LOG_LEVEL=debug
      - LOG_CALLER=hidden
      - TZ=Europe/Berlin
    networks:
      - traefik-proxy
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /X:/updater/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ddns.tls=true"
      - "traefik.docker.network=traefik-proxy"
      - "traefik.http.routers.ddns.tls.certresolver=http"
      - "traefik.http.routers.ddns.entrypoints=http,https"
      - "traefik.http.routers.ddns.rule=Host(`X`)"
      - "traefik.http.services.ddns.loadbalancer.server.port=10000"
      - "com.centurylinklabs.watchtower.enable=true"

Log (Debug):

> 2023-02-12T22:20:29+01:00 INFO reading JSON config from file /updater/data/config.json
> 2023-02-12T22:20:29+01:00 DEBUG config read: {
>   "settings": [
>     {
>       "provider": "ddnss",
>       "provider_ip": true,
>       "domain": "X",
>       "host": "@",
>       "username": "X",
>       "password": "X",
>       "dual_stack": false,
>       "ip_version": "ipv4"
>     },
>     {
>         "provider": "strato",
>         "domain": "X",
>         "host": "@",
>         "password": "X",
>         "ip_version": "ipv4",
>         "provider_ip": true
>       }
>   ]
> }
> 2023-02-12T22:20:29+01:00 INFO Found 2 settings to update records
> 2023-02-12T22:20:33+01:00 INFO Reading history from database: domain X host @
> 2023-02-12T22:20:33+01:00 INFO Reading history from database: domain X @
> 2023-02-12T22:20:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:20:33+01:00 INFO [healthcheck server] listening on 127.0.0.1:9999
> 2023-02-12T22:20:33+01:00 INFO [backup] disabled
> 2023-02-12T22:20:33+01:00 INFO [http server] listening on :10000
> 2023-02-12T22:20:38+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:20:42+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:20:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:21:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:21:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:21:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:21:45+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:22:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:22:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:22:38+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:22:42+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:23:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:23:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:23:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:23:45+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:24:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:24:38+01:00 WARN obtaining ipv4 address: try 1 of 3: Get "https://api.ipify.org": context deadline exceeded
> 2023-02-12T22:24:42+01:00 INFO obtaining ipv4 address: succeeded after 2 tries
> 2023-02-12T22:24:42+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:24:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:24:50+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:25:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false
> 2023-02-12T22:25:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil>
> 2023-02-12T22:25:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
> 2023-02-12T22:25:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update
Originally created by @Plaenkler on GitHub (Feb 12, 2023). After starting the container everything behaves normally. As soon as the web server is accessed there is HTTP 404 and the status of the container changes to unhealthy. There is nothing to see in the log. **Compose:** ```yaml ddns-updater: image: qmcgaw/ddns-updater container_name: ddns restart: always security_opt: - no-new-privileges:true environment: - PERIOD=1m - UPDATE_COOLDOWN_PERIOD=5m - PUBLICIP_FETCHERS=all - PUBLICIP_HTTP_PROVIDERS=all - PUBLICIPV4_HTTP_PROVIDERS=all - PUBLICIPV6_HTTP_PROVIDERS=all - PUBLICIP_DNS_PROVIDERS=all - PUBLICIP_DNS_TIMEOUT=3s - HTTP_TIMEOUT=10s # Web GUI - LISTENING_PORT=10000 - ROOT_URL=/ # Backup - BACKUP_PERIOD=0 # 0 to disable - BACKUP_DIRECTORY=/updater/data # Other - LOG_LEVEL=debug - LOG_CALLER=hidden - TZ=Europe/Berlin networks: - traefik-proxy volumes: - /etc/localtime:/etc/localtime:ro - /var/run/docker.sock:/var/run/docker.sock:ro - /X:/updater/data labels: - "traefik.enable=true" - "traefik.http.routers.ddns.tls=true" - "traefik.docker.network=traefik-proxy" - "traefik.http.routers.ddns.tls.certresolver=http" - "traefik.http.routers.ddns.entrypoints=http,https" - "traefik.http.routers.ddns.rule=Host(`X`)" - "traefik.http.services.ddns.loadbalancer.server.port=10000" - "com.centurylinklabs.watchtower.enable=true" ``` **Log (Debug):** ``` > 2023-02-12T22:20:29+01:00 INFO reading JSON config from file /updater/data/config.json > 2023-02-12T22:20:29+01:00 DEBUG config read: { > "settings": [ > { > "provider": "ddnss", > "provider_ip": true, > "domain": "X", > "host": "@", > "username": "X", > "password": "X", > "dual_stack": false, > "ip_version": "ipv4" > }, > { > "provider": "strato", > "domain": "X", > "host": "@", > "password": "X", > "ip_version": "ipv4", > "provider_ip": true > } > ] > } > 2023-02-12T22:20:29+01:00 INFO Found 2 settings to update records > 2023-02-12T22:20:33+01:00 INFO Reading history from database: domain X host @ > 2023-02-12T22:20:33+01:00 INFO Reading history from database: domain X @ > 2023-02-12T22:20:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:20:33+01:00 INFO [healthcheck server] listening on 127.0.0.1:9999 > 2023-02-12T22:20:33+01:00 INFO [backup] disabled > 2023-02-12T22:20:33+01:00 INFO [http server] listening on :10000 > 2023-02-12T22:20:38+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:20:42+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:20:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:21:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:21:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:21:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:21:45+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:22:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:22:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:22:38+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:22:42+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:23:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:23:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:23:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:23:45+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:24:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:24:38+01:00 WARN obtaining ipv4 address: try 1 of 3: Get "https://api.ipify.org": context deadline exceeded > 2023-02-12T22:24:42+01:00 INFO obtaining ipv4 address: succeeded after 2 tries > 2023-02-12T22:24:42+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:24:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:24:50+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:25:33+01:00 DEBUG configured to fetch IP: v4 or v6: false, v4: true, v6: false > 2023-02-12T22:25:37+01:00 DEBUG your public IP address are: v4 or v6: <nil>, v4: XXX.XXX.XXX.XXX, v6: <nil> > 2023-02-12T22:25:41+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update > 2023-02-12T22:25:46+01:00 DEBUG IPv4 address of X is XXX.XXX.XXX.XXX and your IPv4 address is XXX.XXX.XXX.XXX, skipping update ```
saavagebueno commented 2025-11-20 04:22:04 -05:00
Author
Owner
Copy Link

@jasonla commented on GitHub (Feb 14, 2023):

Minor question, did you expose the port in the compose file?

    image: qmcgaw/ddns-updater
    container_name: ddns-updater
    network_mode: bridge
    ports:
      - 10000:10000/tcp
@jasonla commented on GitHub (Feb 14, 2023): Minor question, did you expose the port in the compose file? ``` ddns-updater: image: qmcgaw/ddns-updater container_name: ddns-updater network_mode: bridge ports: - 10000:10000/tcp ```
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@Plaenkler commented on GitHub (Feb 14, 2023):

The container is located in the external network traefik-proxy the load balancer of Traefik listens to port 10000. Did i miss something? @jasonla Most recently, the container worked flawlessly in this constellation. Only since the last reboot it is unhealthy. Thanks for the support.

@Plaenkler commented on GitHub (Feb 14, 2023): The container is located in the external network _traefik-proxy_ the load balancer of Traefik listens to port 10000. Did i miss something? @jasonla Most recently, the container worked flawlessly in this constellation. Only since the last reboot it is _unhealthy_. Thanks for the support.
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@qdm12 commented on GitHub (Jun 12, 2023):

Maybe it has to do with the trailing slash?
Can you try both the v2.5.0 and latest (pull it) image see if it's resolved today?

@qdm12 commented on GitHub (Jun 12, 2023): Maybe it has to do with the trailing slash? Can you try both the v2.5.0 and latest (pull it) image see if it's resolved today?
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@Plaenkler commented on GitHub (Jun 14, 2023):

I have tried the things and continue to have the same result. Could you provide a sample configuration for Traefik?

@Plaenkler commented on GitHub (Jun 14, 2023): I have tried the things and continue to have the same result. Could you provide a sample configuration for Traefik?
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@LachlanStone commented on GitHub (Jan 9, 2024):

Hey Everyone,

I have found a solution to get the DDNS Host to show under Traefik Reverse Proxy.

Finding:

  • The Container does not respect the labels assigned.
  • The Container Name DNS Records do work
  • Mapping the Container Name DNS Record with the Port does access the DDNS

Solution

This solution will require the use of a File Provider based mapping rather then Docker Provider . The File Method will map the DNS Domain Name to the container name. By default a docker network will have the Container name as a internal DNS Record.

DDNS Traefik File

Bellow I have provided both how to setup the File Provider under the Traefik.yml file and the Configuration

Bellow you will find a example of the Traefik Config File that I use.

  • File Name: Does not matter
  • File Extension: .yml

DDNS File Provider Configuration

{
http:
  routers:
    DDNS:
      rule: "Host(`DNS-Name`)"
      entryPoints:
        - "https"
      middlewares: 
      - DDNS-https-redirect
      tls: {}
      service: DDNS
  middlewares:
    DDNS-https-redirect:
      redirectScheme:
        scheme: https
        permanent: true
  services:
    DDNS:
      loadBalancer:
        servers:
          - url: "http://ContainerName:WebGuiPort"
        passHostHeader: true
}

Traefik.yml Configuration File

providers:
  docker:
    exposedByDefault: false
    # test
    endpoint: 'unix:///var/run/docker.sock'
    watch: true
    swarmMode: false
  file:
    directory: /etc/traefik/conf/
    watch: true
@LachlanStone commented on GitHub (Jan 9, 2024): Hey Everyone, I have found a solution to get the DDNS Host to show under Traefik Reverse Proxy. ## Finding: * The Container does not respect the labels assigned. * The Container Name DNS Records do work * Mapping the Container Name DNS Record with the Port does access the DDNS ## Solution This solution will require the use of a <u> File Provider </u> based mapping rather then <u> Docker Provider </u>. The File Method will map the DNS Domain Name to the container name. By default a docker network will have the Container name as a internal DNS Record. ### DDNS Traefik File Bellow I have provided both how to setup the <u> File Provider </u> under the Traefik.yml file and the Configuration Bellow you will find a example of the Traefik Config File that I use. - File Name: Does not matter - File Extension: .yml #### DDNS File Provider Configuration ```yaml { http: routers: DDNS: rule: "Host(`DNS-Name`)" entryPoints: - "https" middlewares: - DDNS-https-redirect tls: {} service: DDNS middlewares: DDNS-https-redirect: redirectScheme: scheme: https permanent: true services: DDNS: loadBalancer: servers: - url: "http://ContainerName:WebGuiPort" passHostHeader: true } ``` #### Traefik.yml Configuration File ```yaml providers: docker: exposedByDefault: false # test endpoint: 'unix:///var/run/docker.sock' watch: true swarmMode: false file: directory: /etc/traefik/conf/ watch: true ```
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@qdm12 commented on GitHub (Jan 19, 2024):

@Laclan Awesome thanks for the contribution! 💯

The Container does not respect the labels assigned.

Do you have any idea why that is? Is your ddns-updater container healthy/unhealthy? 🤔

@qdm12 commented on GitHub (Jan 19, 2024): @Laclan Awesome thanks for the contribution! 💯 > The Container does not respect the labels assigned. Do you have any idea why that is? Is your ddns-updater container healthy/unhealthy? 🤔
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Feb 14, 2024):

I have same problem: my DDNS container is not picked up by Traefik.
It was.
And now it's not.

It's not in the list of the Traefik's routers or services.

No idea why.

@SlavikCA commented on GitHub (Feb 14, 2024): I have same problem: my DDNS container is not picked up by Traefik. It was. And now it's not. It's not in the list of the Traefik's routers or services. No idea why.
saavagebueno commented 2025-11-20 04:22:05 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Feb 14, 2024):

Found that my DDNS container ignored by Traefik because it's in "unhealthy" state.

And it's in "unhealthy" state because the IP changed for one of my domain. Exact reason why I have ddns-updater and it failed!

And the error is:

...
ddns | 2024-02-15T00:04:17Z INFO [http server] listening on :8000
ddns | 2024-02-15T00:04:17Z INFO [healthcheck server] listening on 127.0.0.1:9999
ddns | 2024-02-15T00:04:17Z INFO ipv4 address of any.****.com is ..84.43 and your ipv4 address is ..72.143
ddns | 2024-02-15T00:04:17Z INFO Updating record [domain: ***.com | host: * | provider: cloudflare | ip: ipv4] to use *..72.143
ddns | 2024-02-15T00:04:18Z ERROR creating record: unsuccessful result: error 81054: A CNAME record with that host already exists. For more details, refer to https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/records-with-same-name/.;

It may be valid error, I'm still checking. But even if it can't create needed CNAME record - it shouldn't fail the healthcheck of the container.

@SlavikCA commented on GitHub (Feb 14, 2024): Found that my DDNS container ignored by Traefik because it's in "unhealthy" state. And it's in "unhealthy" state because the IP changed for one of my domain. Exact reason why I have `ddns-updater` and it failed! And the error is: ... ddns | 2024-02-15T00:04:17Z INFO [http server] listening on :8000 ddns | 2024-02-15T00:04:17Z INFO [healthcheck server] listening on 127.0.0.1:9999 ddns | 2024-02-15T00:04:17Z INFO ipv4 address of any.****.com is **.**.84.43 and your ipv4 address is ***.***.72.143 ddns | 2024-02-15T00:04:17Z INFO Updating record [domain: ***.com | host: * | provider: cloudflare | ip: ipv4] to use ***.**.72.143 ddns | 2024-02-15T00:04:18Z ERROR creating record: unsuccessful result: error 81054: A CNAME record with that host already exists. For more details, refer to <https://developers.cloudflare.com/dns/manage-dns-records/troubleshooting/records-with-same-name/>.; It may be valid error, I'm still checking. But even if it can't create needed CNAME record - it shouldn't fail the healthcheck of the container.
saavagebueno commented 2025-11-20 04:22:06 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Feb 14, 2024):

also, when the container is starting, it stays in the "starting" state for about a minute. Why?
For all that duration, the container is not accessible via Traefik...

@SlavikCA commented on GitHub (Feb 14, 2024): also, when the container is starting, it stays in the "starting" state for about a minute. Why? For all that duration, the container is not accessible via Traefik...
saavagebueno commented 2025-11-20 04:22:06 -05:00
Author
Owner
Copy Link

@qdm12 commented on GitHub (Feb 19, 2024):

To fix this, just disable the docker healthcheck. For example in docker-compose.yml:

healthcheck:
  disable: true

You might want to also subscribe to https://github.com/traefik/traefik/issues/7842 to know when it's possible for Traefik to route to unhealthy or starting containers. Kind of weird they enable this by default 🤔

It may be valid error, I'm still checking. But even if it can't create needed CNAME record - it shouldn't fail the healthcheck of the container.

If one of the record failed to update, the container will go in unhealthy state until it succeeds again. Why shouldn't it fail the healthcheck? 🤔 (relevant code line).

But even if it can't create needed CNAME record

You should have a CNAME or an A record for that owner, you can't have both, so that's a configuration issue, and I feel it's fine for ddns-updater to error out and go in unhealthy state, right?

also, when the container is starting, it stays in the "starting" state for about a minute. Why?

The Docker healthcheck is defined by:

6a6b1a8ebb/Dockerfile (L68)

So it starts at 10 seconds, and then it waits for the 60s interval. You can toy with these settings within your docker-compose.yml as well. It might be interesting to have a more regular interval, although each check performs some DNS lookups so that would be a lot of spam for short periods.

@qdm12 commented on GitHub (Feb 19, 2024): To fix this, just disable the docker healthcheck. For example in docker-compose.yml: ```yml healthcheck: disable: true ``` You might want to also subscribe to https://github.com/traefik/traefik/issues/7842 to know when it's possible for Traefik to route to unhealthy or starting containers. Kind of weird they enable this by default 🤔 > It may be valid error, I'm still checking. But even if it can't create needed CNAME record - it shouldn't fail the healthcheck of the container. If one of the record failed to update, the container will go in unhealthy state until it succeeds again. Why shouldn't it fail the healthcheck? 🤔 ([relevant code line](https://github.com/qdm12/ddns-updater/blob/6a6b1a8ebbaf228f3454d6a1f4a2a61addea6c0d/internal/health/check.go#L29)). > But even if it can't create needed CNAME record You should have a CNAME or an A record for that owner, you can't have both, so that's a configuration issue, and I feel it's fine for ddns-updater to error out and go in unhealthy state, right? > also, when the container is starting, it stays in the "starting" state for about a minute. Why? The Docker healthcheck is defined by: https://github.com/qdm12/ddns-updater/blob/6a6b1a8ebbaf228f3454d6a1f4a2a61addea6c0d/Dockerfile#L68 So it starts at 10 seconds, and then it waits for the 60s interval. You can toy with these settings within your docker-compose.yml as well. It might be interesting to have a more regular interval, although each check performs some DNS lookups so that would be a lot of spam for short periods.
saavagebueno commented 2025-11-20 04:22:06 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Feb 19, 2024):

If one of the record failed to update, the container will go in unhealthy state until it succeeds again. Why shouldn't it fail the healthcheck?

My understanding: the software should differentiate between container errors and app errors.

For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation.

I would think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc.

But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.

@SlavikCA commented on GitHub (Feb 19, 2024): > If one of the record failed to update, the container will go in unhealthy state until it succeeds again. Why shouldn't it fail the healthcheck? My understanding: the software should differentiate between container errors and app errors. For example, if user try to access http://ddns-updater/invalid-url - that's application-level error, it should be logged, but should not result in the container health degradation. I would think the container healthcheck should be downgraded in cases, such as lack of network connectivity (can't response to DNS requests), storage issues (can't read /write) config files, etc. But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.
saavagebueno commented 2025-11-20 04:22:06 -05:00
Author
Owner
Copy Link

@qdm12 commented on GitHub (Feb 19, 2024):

But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health.

I agree, but also it did help me a few times to see the ddns updater as unhealthy to investigate it. I guess we can have shoutrrr configured with it now, so maybe not that needed. The program should store its last kind of critical error, and serve it to the healthcheck program (the same binary ran in another mode in an ephemeral process).
Would you mind creating another issue (copy pasting your comment should do)? Thanks!

Can we then close this issue, since there is a workaround, and I would rather not remove the healthcheck to avoid breaking compatibility elsewhere? 🤔

@qdm12 commented on GitHub (Feb 19, 2024): > But app-level errors (such as error response from Cloudflare API) should be logged, displayed in UI, but not affect container health. I agree, but also it did help me a few times to see the ddns updater as unhealthy to investigate it. I guess we can have shoutrrr configured with it now, so maybe not that needed. The program should store its last kind of critical error, and serve it to the healthcheck program (the same binary ran in another mode in an ephemeral process). Would you mind creating another issue (copy pasting your comment should do)? Thanks! Can we then close this issue, since there is a workaround, and I would rather not remove the healthcheck to avoid breaking compatibility elsewhere? 🤔
saavagebueno commented 2025-11-20 04:22:06 -05:00
Author
Owner
Copy Link

@SlavikCA commented on GitHub (Feb 19, 2024):

Created https://github.com/qdm12/ddns-updater/issues/656

I can't close this issue. I think only @Plaenkler can (author) or maintainer.

@SlavikCA commented on GitHub (Feb 19, 2024): Created https://github.com/qdm12/ddns-updater/issues/656 I can't close this issue. I think only @Plaenkler can (author) or maintainer.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Category: Config problem 📝
Category: Database 🗃️
Category: Documentation ✒️
Category: Foolproof settings 👼
Category: Good idea 🎯
Category: Healthcheck 🩺
Category: IP fetching 📥
Category: Label missing ❗
Category: Maintenance ⛓️
Category: Motivated! 🙌
Category: New provider 🆕
Category: Provider update ♻️
Category: Shoutrrr 📢
Category: Web UI 🖱️
Category: Wildcard 🃏
Closed: ⚰️ Inactive
Closed: 👥 Duplicate
Closed: 🗑️ Bad issue
Complexity: ☣️ Hard to do
Complexity: 🟩 Easy to do
Priority: 💤 Low priority
Priority: 🚨 Urgent
pull-request
Mirrored from GitHub Pull Request
 Status: 🔒 After next release
Status: 🔴 Blocked
Status: 🗯️ Waiting for feedback
No Label Category: Documentation ✒️ Category: Healthcheck 🩺 Priority: 💤 Low priority Status: 🗯️ Waiting for feedback
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ddns-updater#256
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?