How can I automate and automatic restart of the cloudflared service on a Raspberry Pi

I am using the Pi as a VPN/DOH router which works but ever now and again I get errors and have to restart the cloudflared services.

  1. All seems to work but shortly after a few hours the cloudflared service needs to be restarted.
  2. Also ever present error i get when I run $ cloudflared, I get the following response.

I have installed on the raspberry pi the following:

  1. Raspberry Pi OS Buster Lite (32bit)
  2. pi-hole
  3. DNS-Over-HTTPS (cloudflare) with Pi-hole
  1. ExpressVPN

Output from [email protected]:/ $ cloudflared
INFO[2020-10-01T16:17:58+01:00] terminating due to error: Cannot start the DNS over HTTPS proxy server: failed to create a UDP listener: listen udp 127.0.0.1:5053: bind: address already in use
ERROR[2020-10-01T16:17:58+01:00] Quitting due to error: Cannot start the DNS over HTTPS proxy server: failed to create a UDP listener: listen udp 127.0.0.1:5053: bind: address already in use
INFO[2020-10-01T16:17:59+01:00] Metrics server stopped

So my questions are:

  1. How can I automate the periodic restart of the service via contab.
  2. Is this Error ‘Quitting due to error: Cannot start the DNS over HTTPS proxy server: failed to create a UDP listener: listen udp 127.0.0.1:5053: bind: address already in use’ something I need to be worried about.

The listen udp 127.0.0.1:5053 bind: address already in use error is something similar to what I experienced running NextDNS DoH from my Linux box. I attempted using :5353 which is obviously the port used by multiplexing. I went root & edited the NextDNS config file to make it listen on the normal :53 UDP port used by unencrypted DNS. As it turns out, so long as outgoing queries are sent via :443 at the DNS level (which is the norm for the DoH proto), all is good insofar as that end of it goes. And since that occurs “automatically” once the requests go out to DNS, so long as you’re unconcerned with that short “first mile” going out to DNS unencrypted, I suggest attempting doing to the Cloudflared daemon config what I did to the NextDNS daemon config. If that’s not possible (not a Cloudflared user… yet) the next suggestion is a Cron job that gets triggered to restart the Cloudflared daemon when it goes down while you look into what is occupying that particular port. I won’t go into the obvious things to look at such as FW settings. Hopefully this is helpful in part at least. Oh, also, I thought Cloudflared listened on TCP 5053 not UDP?

Sorry for the delay been working on other things, and only just got back round to this, I am still having issues in understanding the log output, from this I see past errors but no conformation that the systems state has changed.

$ sudo systemctl status cloudflared

when the system seems fine I see:

Oct 15 06:57:41 blackhole.cfts.co systemd[1]: Started Argo Tunnel.
Oct 15 06:57:41 blackhole.cfts.co cloudflared[14286]: INFO[2020-10-15T06:57:41+01:00] Adding DNS upstream - url: https://1.1.1.1/dns-query
Oct 15 06:57:41 blackhole.cfts.co cloudflared[14286]: INFO[2020-10-15T06:57:41+01:00] Adding DNS upstream - url: https://1.0.0.1/dns-query
Oct 15 06:57:41 blackhole.cfts.co cloudflared[14286]: INFO[2020-10-15T06:57:41+01:00] Starting metrics server on 127.0.0.1:37391/metrics
Oct 15 06:57:41 blackhole.cfts.co cloudflared[14286]: INFO[2020-10-15T06:57:41+01:00] Starting DNS over HTTPS proxy server on: dns://localhost

When its not i see:

    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 04:09:00 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T04:09:00+01:00] failed to connect to an HTTPS backend "https://1.0.0.1/d
    Oct 15 06:13:43 blackhole.cfts.co cloudflared[2166]: ERROR[2020-10-15T06:13:43+01:00] failed to connect to an HTTPS backend "https://1.1.1.1/d

When it is in this state the DOH and domain resolution do not work

Whats perplexing is that I have no idea if the system is in a failed state or not? the times are clearly seen but no conformation of state change back to operational?

Am I being a bone head here, there just seems to be no positive verification that the service is behaving as expected once it gets a failed state, its getting quite frustrating to trouble shoot.

It should be noted when the system is in a failed state it can take some time to restart the service 5 mins or more? not all the time but enough to be annoying,.

I don’t mind paying for a service if that what it takes but I do not want to move my domains over to cloudflare or indeed any other provider, i just want to be able to use the DOH service.

OK found the issue seems to be cloudflares, https://github.com/cloudflare/cloudflared/issues/91

so the upshot were now using dnscrypt which seems to be far more stable, but will know in a couple of days to be sure, that been said dns resolves much faster even when using 1.1.1.1

Oct 15 14:41:09 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:09] [NOTICE] Network not available yet -- waiting...
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Network connectivity detected
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Now listening to 127.0.0.1:5053 [UDP]
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Now listening to 127.0.0.1:5053 [TCP]
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Source [public-resolvers] loaded
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Source [relays] loaded
Oct 15 14:41:21 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:21] [NOTICE] Firefox workaround initialized
Oct 15 14:41:23 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:23] [NOTICE] [cloudflare] OK (DoH) - rtt: 66ms
Oct 15 14:41:23 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:23] [NOTICE] Server with the lowest initial latency: cloudflare (rtt: 66ms)
Oct 15 14:41:23 blackhole.cfts.co dnscrypt-proxy[378]: [2020-10-15 14:41:23] [NOTICE] dnscrypt-proxy is ready - live servers: 1

Awesome. Yeah, I like DNSCrypt more so than DoH. It’s codebase is simply more mature.

(Attachment publicKey - [email protected] - dc622ac9.asc is missing)

Oh, SystemD… check out SysV & Runit for alternative init systems. SysV has a SystemD shim to allow it to use software designed for SystemD.

(Attachment publicKey - [email protected] - dc622ac9.asc is missing)

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.