Cache issues in v3.10 about ddclient

[LenardHess]

ddclient#511 Issue in comment
tl;dr: Invalid config file

@tsjk

The log message mentions protocol <undefined> is not supported.
This is due to the configuration file - the host lines are required to be either in a single line or with escaped multilines (a '\' character at the end)

ddclient.conf

daemon=300                                              # check every 300 seconds
syslog=yes                                              # log update msgs to syslog
ssl=yes                                                 # use ssl-support -- works with ssl-library
use=if, if=net1                                         # get ip via interface

protocol=dyndns2                                        # default protocol
server=members.dyndns.org                               # default server
login=<snip>
password=<snip>
backupmx=no                                             # host is primary MX?
wildcard=yes                                            # add wildcard CNAME?

<hostname>

Error Log

ddclient[16764]: FAILED:   updating <hostname>: unexpected status (12)
ddclient[16764]: WARNING:  updating : nochg: No update required; unnecessary attempts to change to the current address are considered abusive
ddclient[16764]: FAILED:   updating : unexpected status (0)
ddclient[16764]: FAILED:    was not updated because protocol <undefined> is not supported.

[LenardHess]

ddclient#511
tl;dr: Lack of sleeping between updates is due to missing daemon parameter and the linuxserver.io container instantly auto-restarting ddclient

@cmjordan42

The Linuxserver.io container runs ddclient via /usr/bin/ddclient -foreground -file /ddclient.conf (see here)
There is no -daemon parameter supplied in the call.

If the conf file is missing the daemon parameter this causes ddclient to exit after attempting to update.
In turn, the s6 layer in the container will then restart the ddclient process, causing the loop as described.

To reproduce, put the files below into the same folder, then run docker-compose up
The log will show the same loop (plus errors failing to resolve fakeserver.local)

ddns  | WARNING:  cannot connect to fakeserver.foo:443 socket: Name does not resolve IO::Socket::IP configuration failed
ddns  | FAILED:   updating domain.example.org: Could not connect to fakeserver.foo.
ddns  | WARNING:  skipping update of domain.example.org from <nothing> to 79.246.73.144.
ddns  | WARNING:  last updated <never> but last attempt on Sun Jul  9 12:06:05 2023 failed.
ddns  | WARNING:  Wait at least 5 minutes between update attempts.
ddns  | WARNING:  cannot connect to fakeserver.local:443 socket: Name does not resolve IO::Socket::IP configuration failed
ddns  | FAILED:   updating domain.example.org: Could not connect to fakeserver.local.
ddns  | WARNING:  skipping update of domain.example.org from <nothing> to 79.246.73.144.
ddns  | WARNING:  last updated <never> but last attempt on Sun Jul  9 12:06:08 2023 failed.
ddns  | WARNING:  Wait at least 5 minutes between update attempts.
ddns  | WARNING:  cannot connect to fakeserver.local:443 socket: Name does not resolve IO::Socket::IP configuration failed
ddns  | FAILED:   updating domain.example.org: Could not connect to fakeserver.local.
ddns  | WARNING:  found neither IPv4 nor IPv6 address
ddns  | WARNING:  domain.example.org: unable to determine IP address with strategy use=web
ddns  | Use of uninitialized value $_[2] in sprintf at /usr/bin/ddclient line 2160.
ddns  | WARNING:  skipping update of domain.example.org from <nothing> to .
ddns  | WARNING:  last updated <never> but last attempt on Sun Jul  9 12:06:11 2023 failed.
ddns  | WARNING:  Wait at least 5 minutes between update attempts.
ddns  | WARNING:  IP address for domain.example.org undefined. Warned 1 times, suppressing further warnings
ddns  | WARNING:  cannot connect to fakeserver.local:443 socket: Name does not resolve IO::Socket::IP configuration failed
ddns  | FAILED:   updating domain.example.org: Could not connect to fakeserver.local.
ddns  | WARNING:  skipping update of domain.example.org from <nothing> to 79.246.73.144.
ddns  | WARNING:  last updated <never> but last attempt on Sun Jul  9 12:06:15 2023 failed.
ddns  | WARNING:  Wait at least 5 minutes between update attempts.
ddns  | WARNING:  cannot connect to fakeserver.local:443 socket: Name does not resolve IO::Socket::IP configuration failed
ddns  | FAILED:   updating domain.example.org: Could not connect to fakeserver.local.
ddns  | WARNING:  skipping update of domain.example.org from <nothing> to 79.246.73.144.
ddns  | WARNING:  last updated <never> but last attempt on Sun Jul  9 12:06:18 2023 failed.

---

Test files:
ddclient.conf

#daemon=5m # Loop appears while this is commented out.

# Configure the domain (using fake credentials and DDNS server)
use=web, \
web=checkip.dyndns.org, \
protocol=duckdns, \
server=fakeserver.local, \
password=asdf \
domain.example.org

docker-compose.yml

services:
  ddns:
    container_name: ddns
    image: linuxserver/ddclient
    environment:
      PUID: 1000
      PGID: 1000
      TZ: Germany/Berlin
    volumes:
      - ./ddclient.conf:/config/ddclient.conf
    restart: unless-stopped

[rrthomas]

I think the key issue is: ddclient#431

Also, I am not experiencing this problem as far as I can tell with DNSExit v2. (I mostly use mythicdyn, which has no way to tell the current address, so always updates, and has no rate limits.)

[nemchik]

We can adjust our container init logic to sleep infinity if the conf file is missing. We run it in the foreground to allow s6 to supervise the process, and any output from the process appears in the container log.

[LenardHess]

I haven't finished looking into this yet, but it seems you can 'daemonize' without forking by combining -foreground and -daemon to do the daemon-style loop without forking first.
I won't recommend doing that until I looked further into it - and then i'll be opening an issue and/or pull request in the lsio ddclient repo for that.

[LenardHess]

@GrantEdwards @fabian727 @R-Adrian @Saturn49
Would any of you be available to troubleshoot your ddclient issues?

If possible, share your (redacted!) ddclient.conf, log, and cache files and version you're running

[GrantEdwards]

@GrantEdwards @fabian727 @R-Adrian @Saturn49 Would any of you be available to troubleshoot your ddclient issues?

Sorry, I'm no longer using ddlclient and don't have it installed.

[Saturn49]

I fixed my issues with a (local) patch to nic_cloudflare_update():

                if ($response && $response->{result}) {
                    success("updating %s: IPv$ipv address set to %s", $domain, $ip);
                    $config{$domain}{"ipv$ipv"} = $ip;
                    $config{$domain}{'mtime'} = $now;
                    $config{$domain}{"status-ipv$ipv"} = 'good';

                    #++
                    if ($ipv == "4") {
                        $config{$domain}{"ip"} = $ip;
                        $config{$domain}{"status"} = 'good';
                    }
                    # --
                } else {
                    failed("updating %s: invalid json or result.", $domain);
                }

I detailed this in ddclient#481

This prevents the check to $config{$domain}{"status'} from failing elsewhere (can't remember exactly where)

my ddclient.conf has:

use=web
usev6=disabled
# Cloudflare
protocol=cloudflare
zone=my_zone.com
ttl=1
server=api.cloudflare.com/client/v4
login=token
password=my_password
my_zone.com

The code (as written) has both use and usev4 which sorta mean the same thing (and corresponding status and status-ipv4) but one is updated in the cache but not the other.

IMHO, the use of 'status', 'ip' and 'use' should be eliminated in the code, and any existing use of 'use' in a config file should be translated to 'usev4', but this is non-trivial and would affect nearly every function.

[LenardHess]

Thanks for the quick replies!

'use', 'status' and 'ip' are all meant to be deprecated, and yes - its going to be a good chunk of work to do so.

From looking at it briefly, caching for cloudflare seems to be broken when using 'use' due to a missing assignment to 'status' in nic_cloudflare_update. Your change does mitigate that issue. Switching to 'usev4' would be the other workaround.

The proper fix will be a review of the rules around 'use[-v4|-v6]' and friends and the usage of the different providers thereof.

[fabian727]

I am sorry. I also uninstalled and replaced with a short script.
As far as I remember, all parameters were line separated.

[rrthomas]

Great to see this fixed!