mirror of
https://github.com/qdm12/ddns-updater.git
synced 2026-08-02 10:38:41 -04:00
Bug: Stuck in the 'Deploying' STate #480
Assignees
saavagebueno
Clear assignees
saavagebueno
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/ddns-updater#480
Reference in New Issue
Block a user
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?
Originally created by @khowe085 on GitHub (Jan 1, 2025).
TLDR: I deployed the application to TrueNAS Scale v24.10 and it is stuck in the 'deploying' state even though it is actively updating my IP address as expected
78f3061)AFAIK This version of TrueNAS scale is using docker. They have a UI system that provides fields and then builds the container (presumably with docker compose) from that input. I haven't been able to find the actual yaml file in the UI though.
Logs:
Host OS: TrueNAS Scale v24.10
@briveramelo commented on GitHub (Jan 1, 2025):
also experiencing this on TrueNAS Scale v24.10, same conditions
@haldi4803 commented on GitHub (Jan 2, 2025):
it's running well, except:
2025-01-02 17:17:53.817210+00:002025-01-02T18:17:53+01:00 INFO reading JSON config from environment variable CONFIG
2025-01-02 17:17:53.817219+00:002025-01-02T18:17:53+01:00 INFO reading JSON config from file /updater/data/config.json
2025-01-02 17:17:53.817227+00:002025-01-02T18:17:53+01:00 WARN Found no setting to update record
config.json gets overwritten everytime the container starts...
Scale v24.10
Edit: There is now a "Config" option in TrueNAS... so config.json is deprecated -.-
@khowe085 commented on GitHub (Jan 8, 2025):
Crossed-posted this with the Over at TrueNAS apps. Give it a read @haldi4803.
Turns out that, for me anyway, this is because I have a custom DNS rule on my router that loops my domain back to the the local server. DDNS-Updater doesn't like that, and in turn fails the health check that determines if the app is running or still deploying. They closed the issue as it 'behaves as intended' from the view of TrueNAS Apps.
From a DDNS-Updater perspective, I don't know why it doesn't like it when I have this rule in place. I would argue that this should probably be logged as a warning rather than failing the health check. In mu case this rule was setup so that I can access my apps through a reverse proxy (on the NAS), using my public domain / certs, without having to permanently open port 443.
Here is the error that the related to the health check failure.
2025-01-07T21:09:50-05:00 ERROR program is unhealthy: lookup IP addresses do not match: {NAS private IP} instead of {my public IP} for {mydomain}\n\n2025-01-07T21:09:50-05:00 INFO Shutdown successful\n@tina-junold commented on GitHub (Mar 19, 2025):
Same problem here, it would be cool to give ddns-updater the possibility to set the dns server like in some other apps.
@starlink89 commented on GitHub (Mar 23, 2025):
I had the same problem, I'm using pihole as dns in my router, just change my dns to manual in my host, reinstall the container and boom!!
Works perfect now
@8aXaJzvh commented on GitHub (Mar 28, 2025):
For anyone else having this issue. I worked around the issue by specifying a dns server in the ddns-updater docker-compose file.
I found mine in the following location.
/mnt/.ix-apps/app_configs/ddns-updater/versions/1.0.0/templates/rendered/docker-compose.yaml@JimmyRascon commented on GitHub (Mar 31, 2025):
I encountered the same problem in TrueNAS, but after setting this environment variable in the app settings, it now shows as 'Running'.
RESOLVER_ADDRESS: 8.8.8.8:53@Sophist-UK commented on GitHub (May 14, 2025):
I am experiencing this problem.
I tried opening a container shell to run
/updater/ddns-updater healthcheckbut the container shell wouldn't connect.@Sophist-UK commented on GitHub (May 14, 2025):
I tried this:
and the container log says:
but it made no difference for me - the app stayed in
Deployingstatus.@DragonQ commented on GitHub (May 28, 2025):
Thanks, this fixed the issue for me. It was because I have a local DNS entry on my host system pointing "mydomain.com" to its local IP, which was then confusing the healthcheck because it was comparing the local IP to the external IP and finding them to be different. It meant my container was constantly being restarted every minute and never exiting the "starting" state.
I now have 5368 IP "changes" (in fact they are all the same) to manually delete from the
updates.jsonfile! :)Are you perhaps overriding the DNS somewhere, like a forwarding rule on your router? I do this to ensure my Pihole is used by everything but I have my main server excluded from the rule because (a) I trust it, and (b) issues like this!
@rex commented on GitHub (Sep 22, 2025):
@Sophist-UK Just FYI, you included sensitive security credentials in your debug output. I highly advise you to update your comment to remove those credentials and then change whatever passwords you accidentally exposed. I really think you should do that ASAP.
@Sophist-UK commented on GitHub (Oct 14, 2025):
Same problem again. Deleting updates.json didn't solve it this time.
@rolledback commented on GitHub (Oct 30, 2025):
In my case, the problem appears to be that I have DNS proxying turned on at my DNS provider. Seems like something that you should be able to add to your config...
@rolledback commented on GitHub (Oct 30, 2025):
Ah lovely, you can set
"proxied": truefor CloudFlare domains. 😄 This has fixed the issue for me.