cf-ddns-v4/v6 CPU causes 100% CPU usage 24/7

[nflaig]

• See 100% CPU usage and spawns process for host user joshuaavalon/docker-cloudflare#79

Just reporting this back here to consider disabling container until this is fixed, it caused my CPU temp to drastically increase to almost 100°C.

[nflaig]

Looks like it is not required to run 2 containers for v4 and v6, see joshuaavalon/docker-cloudflare#79 (comment).

[yorickdowne]

Interesting. I'll take a look to run just one container

[yorickdowne]

Thanks for digging into this with the dev of cf-ddns. I've combined v4/6 into one container

[yorickdowne]

CPU temp sounds more like a hardware issue. Power Level 1/2 should be set for a NUC, to TDPlow for the CPU and ~1.25x that. While cf-ddns shouldn't take 100% CPU; similarly the hardware shouldn't overheat when CPU is maxed for a long time.

[nflaig]

CPU temp sounds more like a hardware issue. Power Level 1/2 should be set for a NUC, to TDPlow for the CPU and ~1.25x that.

Thanks, will look into this

[yorickdowne]

Can you see whether 3.1.0 resolves this in your environment? A simple ./ethd update should bring it in

[nflaig]

Can you see whether 3.1.0 resolves this in your environment?

Already deployed 3.1.0 but it will be hard to confirm if it fixes the issue, it has been really inconsistent for me as well.

[nflaig]

Closing as the issue will be fixed with cloudflare-ddns v3.2.1

[yorickdowne]

Mayyyybe fixed. Turns out cloudflare-ddns had a bug and stopped updating records. So fixed bcs fixed or fixed bcs it stopped doing work?

[nflaig]

There are a bunch of errors in the logs but also a success log.

INFO (133): Updated <record> with <ip>

I updated to latest version 3.2.3 now and will keep an eye on that.

[nflaig]

This doesn't look good though joshuaavalon/docker-cloudflare#79 (comment).

Edit: Referenced comment got deleted, maybe we are good? Let's wait and see

[yorickdowne]

The answer may be to investigate https://github.com/timothymiller/cloudflare-ddns. Just sticking this here for reference for now.

...

I remember why I didn't use this. It is missing a few features. It can't look up zone ID from the domain name; it is configured via a json file only; it doesn't do "split permission tokens", as in one with read for all zones and then a write for just a specific zone.

That said ... this 100% CPU stuff is getting old.

[yorickdowne]

No particularly good choices here. Go with another image that has some missing features, or try and fix the existing image, as the dev won't.

"This docker is just cron job running a Node.js script. If you see my replies above, my best guest is the related to base Docker image cron.

There are really nothing I can changed. You can try different base image to see anything different."

[nflaig]

I just have the container stopped at the moment and if my server IP changes I just start it a few minutes and stop it again which is sufficient to update the dns records. This works for me but requires additional effort to have it automated.

[yorickdowne]

Hang loose and wait for joshuaavalon/docker-cloudflare#96 .

[yorickdowne]

Well, we need a new idea. "This repository has been archived by the owner on Jan 28, 2024"

[yorickdowne]

We could use this. It needs the Zone ID, which isn't the most friendly thing - but with the existing variables, maybe an entrypoint script could get this for the user.

https://github.com/qdm12/ddns-updater/blob/master/docs/cloudflare.md

[yorickdowne]

@nflaig You're probably the heaviest user here. I am pondering requiring CF_ZONE_ID, populating it during ./ethd update for existing users, and getting rid of the requirement to have Zone.Zone:Read and Zone.Zone Settings: Read permissions across all Zones. Arguably UX is no worse when requiring the ID, and security is better.

Thoughts?

[nflaig]

Thoughts?

Sounds good to me, I just have a single zone in the cf account I use for this but it's generally good idea to limit permissions to a minimum.

[yorickdowne]

This is in. IPv4 only right now since upstream doesn't have ipv4-and-ipv6 yet. That's coming: qdm12/ddns-updater#507

[yorickdowne]

Turns out traefik wants those permissions, so I don't have a way around that right now