Are you using Stubby or Cloudflared for your encrypted DNS (or both)? You noted that both were installed, but are you using both?
On one of the systems, cloudflared is installed (127.0.0.1:5053), but disabled using systemctl.
The third system I am talking about in my last posts does not contain cloudflared.
What is the output of this command? journalctl -u pihole-FTL
There must be some reason it does not start.
There is no error message at all:
service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)
root@cube:/home/pi# journalctl -u pihole-FTL
-- Logs begin at Tue 2019-02-19 16:14:10 CET, end at Tue 2019-02-19 16:20:01 CET
-- No entries --
The logs were rotated 6 minutes before you ran that command. Please run sudo service pihole-FTL restart and then the journalctl command again.
After a reboot, pihole-FTL does not work, and journal is empty. I have reproduced this several times now:
service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)
root@cube:/home/pi# journalctl -u pihole-FTL
-- Logs begin at Wed 2019-02-20 16:35:47 CET, end at Wed 2019-02-20 16:52:18 CET.
-- No entries --
After restarting the service, pihole works as expected. No pihole-FTL errors in journal:
service pihole-FTL restart
root@cube:/home/pi# service pihole-FTL status -l
● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: active (exited) since Wed 2019-02-20 16:54:17 CET; 4s ago
Docs: man:systemd-sysv-generator(8)
Process: 827 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCE
journalctl -u pihole-FTL
Feb 20 16:54:06 cube systemd[1]: Starting LSB: pihole-FTL daemon...
Feb 20 16:54:06 cube pihole-FTL[827]: Not running
Feb 20 16:54:17 cube su[880]: (to pihole) root on none
Feb 20 16:54:17 cube su[880]: pam_unix(su:session): session opened for user pih
Feb 20 16:54:17 cube pihole-FTL[827]: FTL started!
Feb 20 16:54:17 cube su[880]: pam_unix(su:session): session closed for user pih
Feb 20 16:54:17 cube systemd[1]: Started LSB: pihole-FTL daemon.
This seems to me in line with delaying the stubby.service for 30 seconds like mentioned here:
btw: where does dnsmasq write its logs to?
Dnsmasq logs go to /var/log/pihole.log
It looks like stubby conflicts on some ports with FTL.
And maybe cloudflared, too.
Nope.
netstat shows cloudflared listening on port 5053 which is not conflicting with pihole-FTL.
stubby though is conflicting on DNS port 53 UDP:
I gave stubby 127.0.0.2 on all of my three setups,
while dnsmasq/pihole remain on 127.0.0.1:53.
Still pihole-FTL does not autostart after reboot, when using
conventional unit files. If the autostart is delayed, pihole-FTL
starts as expected.
Also, on one pihole with cloudflared (EDIT: 127.0.0.1:5053, sorry for the typo) pihole-FTL
does not autostart.
To me, netstat monitoring can give hints during runtime.
But it does not show what happens at boot time.
Is there a way to monitor this?
On the system that runs pihole-FTL, stubby and cloudflared I checked netstat some days ago allready.
There is no obvious conflict concerning the listening address. Each of the three services uses its own set of ip address and port.
sudo grep -v '^#\|^$' -R /etc/dnsmasq.*
?
Might want to edit out some details!
Could try ad below directive in seperate new config file /etc/dnsmasq.d/99-my-settings.conf:
bind-interfaces
pihole-FTL might skip trying to bind to that 127.0.0.2 ip and hopefully start.
Or else you need to configure pihole-FTL to only listen on particular IP's.
And same with stubby ... need to tell it to only listen on 127.0.0.2.
EDIT:
Ah, thank you for this supplement 
Is there anything I can do now?
Can we expect further investigation of this issue from dnsmasq developers?
Or should I contact them myself?
This bit is not true I believe.
With default configuration of Pi-hole, the pihole-FTL daemon tries to bind to all IP's 0.0.0.0
So to prevent, you need to force pihole-FTL to listen/bind only on particular IP's.
Nothing wrong with Pi-hole and I dont believe the devs can do allot about it.
1 Like
I now tried bind-interfaces, and listen-address,
and both options together in /etc/dnsmasq.d/99-my-settings.conf, like here:
listen-address=::1,127.0.0.1,192.168.73.121
bind-interfaces
It doesnt change anything concerning the autostart of pihole -- it does not start at boot time.
It starts only on runtime, if stubby is configured to autostart, too.
Stubby is still listening on its own interface 127.0.0.2.
On the second of three systems I use, I configured stubby for 127.0.0.11.
It should not and it does not make a difference, pihole does not autostart.
If you get pihole-FTL to run, how does a netstat look like now ?
Does it only listen now to the IP's you configured in 99-my-settings.conf ?
EDIT: Ohw and this bit:
To me, after a reboot an manually starting pihole-FTL everything looks as it should.
What I did before these monitoring commands:
-
rebooted the system
-
logged in and checked, if pihole was running
-
systemctl status pihole-FTL● pihole-FTL.service - LSB: pihole-FTL daemon
Loaded: loaded (/etc/init.d/pihole-FTL; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8) -
systemctl restart pihole-FTLnetstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471 \|10053' Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 655/lighttpd tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 887/pihole-FTL tcp 0 0 127.0.0.2:10053 0.0.0.0:* LISTEN 553/stubby tcp6 0 0 :::80 :::* LISTEN 655/lighttpd tcp6 0 0 :::53 :::* LISTEN 887/pihole-FTL udp 0 0 0.0.0.0:53 0.0.0.0:* 887/pihole-FTL udp 0 0 0.0.0.0:67 0.0.0.0:* 887/pihole-FTL udp 0 0 127.0.0.2:10053 0.0.0.0:* 553/stubby udp6 0 0 :::53 :::* 887/pihole-FTLgrep -v '^#|^$' -R /etc/dnsmasq.*
/etc/dnsmasq.conf:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.d/99-my-settings.conf:listen-address=::1,127.0.0.1,192.168.73.121
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/gravity.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/black.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:localise-queries
/etc/dnsmasq.d/01-pihole.conf:no-resolv
/etc/dnsmasq.d/01-pihole.conf:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:log-queries
/etc/dnsmasq.d/01-pihole.conf:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:log-async
/etc/dnsmasq.d/01-pihole.conf:dhcp-name-match=set:wpad-ignore,wpad
/etc/dnsmasq.d/01-pihole.conf:dhcp-ignore-names=tag:wpad-ignore
/etc/dnsmasq.d/01-pihole.conf:server=1.1.1.1
/etc/dnsmasq.d/01-pihole.conf:domain-needed
/etc/dnsmasq.d/01-pihole.conf:bogus-priv
/etc/dnsmasq.d/01-pihole.conf:dnssec
/etc/dnsmasq.d/01-pihole.conf:trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
/etc/dnsmasq.d/01-pihole.conf:trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
/etc/dnsmasq.d/01-pihole.conf:local-service
/etc/dnsmasq.d/02-pihole-dhcp.conf:dhcp-authoritative
/etc/dnsmasq.d/02-pihole-dhcp.conf:dhcp-range=192.168.222.201,192.168.222.251,24h
/etc/dnsmasq.d/02-pihole-dhcp.conf:dhcp-option=option:router,192.168.222.1
/etc/dnsmasq.d/02-pihole-dhcp.conf:dhcp-leasefile=/etc/pihole/dhcp.leases
/etc/dnsmasq.d/02-pihole-dhcp.conf:domain=lan
And just for the record, before starting pihole-FTL manually, it does not listen on port 53 (on port 5353 Avahi is listening):
netstat -an|grep 53
tcp 0 0 127.0.0.2:10053 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 127.0.0.2:10053 0.0.0.0:*
udp6 0 0 :::5353 :::*
unix 2 [ ] DGRAM 8536
unix 3 [ ] STREAM VERBUNDEN 13553
root@cube:/home/pi# netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471 \|10053'
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 655/lighttpd
tcp 0 0 127.0.0.2:10053 0.0.0.0:* LISTEN 553/stubby
tcp6 0 0 :::80 :::* LISTEN 655/lighttpd
udp 0 0 127.0.0.2:10053 0.0.0.0:* 553/stubbypihole-FTL is still trying to bind to all 0.0.0.0
I miss the bind-interfaces directive in the 99-my-settings.conf file ?
And it seems stubby port has changed to 10053 ?
1 Like