Pi-hole DNS service not running after first install

noads · October 19, 2020, 5:19am

Please follow the below template, it will help us to help you!

Expected Behaviour:

Pi-hole DNS service should be running. This is a first-time install.
OS: Raspbian GNU/Linux 9 (stretch)
Hardware: Raspberry Pi Zero W

Actual Behaviour:

DNS service is not running. From the log file it seems like name resolution is failing via localhost and via Pi-hole.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve rutrk.org via localhost (127.0.0.1)
[✗] Failed to resolve rutrk.org via Pi-hole ([pi-hole ip address])
[✓] doubleclick.com is 172.217.12.206 via a remote, public DNS server (8.8.8.8)

Debug Token:

https://tricorder.pi-hole.net/unezzfqw0v

Troubleshooting:

pihole status - DNS service is NOT running
pihole enable - blocking already enabled, nothing to do
pihole restartdns - Restarting DNS server
Nothing found in pi-hole diagnosis

dig @127.0.0.1 google.com
DiG 9.10.3-P4-Raspbian (at)127.0.0.1 google .com
(1 server found)
global options: +cmd
connection timed out; no servers could be reached

Bucking_Horn · October 19, 2020, 7:01am

Your debug log shows Pi-hole to be active, but it isn't binding port 53:

*** [ DIAGNOSING ]: Ports in use
*:5900 vncserver- (IPv6)
*:5900 vncserver- (IPv4)
*:22 sshd (IPv4)
*:22 sshd (IPv6)
[80] is in use by lighttpd
[80] is in use by lighttpd

*** [ DIAGNOSING ]: Pi-hole processes
[✓] lighttpd daemon is active
[✓] pihole-FTL daemon is active

What's the output of

sudo ss -tulpn | grep "Netid\|:53 "

noads · October 19, 2020, 1:59pm

Thanks for the response.

 sudo ss -tulpn | grep "Netid\|:53 "

gives


Netid State      Recv-Q Send-Q Local Address:Port               Peer Address:Port

and

sudo ss -tulpn

gives

Netid State      Recv-Q Send-Q Local Address:Port               Peer Address:Port            
tcp   LISTEN     0      5                *:5900                         *:*                   users:(("vncserver-x11-c",pid=436,fd=10))
tcp   LISTEN     0      128              *:80                           *:*                   users:(("lighttpd",pid=487,fd=4))
tcp   LISTEN     0      128              *:22                           *:*                   users:(("sshd",pid=473,fd=3))
tcp   LISTEN     0      5               :::5900                        :::*                   users:(("vncserver-x11-c",pid=436,fd=9))
tcp   LISTEN     0      128             :::80                          :::*                   users:(("lighttpd",pid=487,fd=5))
tcp   LISTEN     0      128             :::22                          :::*                   users:(("sshd",pid=473,fd=4))

EDIT
I did some more testing as well, in the dashboard it says FTL is offline, however, I see the following:

systemctl status pihole-FTL

gives

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
   Active: active (exited) since Mon 2020-10-19 15:05:28 EDT; 1h 38min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 10587 ExecStop=/etc/init.d/pihole-FTL stop (code=exited, status=0/SUCCESS)
  Process: 10592 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/pihole-FTL.service

Oct 19 15:05:26 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Oct 19 15:05:26 raspberrypi pihole-FTL[10592]: Not running
Oct 19 15:05:27 raspberrypi su[10610]: Successful su for pihole by root
Oct 19 15:05:27 raspberrypi su[10610]: + ??? root:pihole
Oct 19 15:05:27 raspberrypi su[10610]: pam_unix(su:session): session opened for user pihole by (uid=0)
Oct 19 15:05:28 raspberrypi pihole-FTL[10592]: dnsmasq: cannot open or create lease file /var/lib/misc/dnsmasq.leases: Permission denied
Oct 19 15:05:28 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

I am investigating the dnsmasq issue.

EDIT 2
Following this thread, I ran sudo chown pihole:pihole /var/lib/misc/dnsmasq.leases
after confirming that the dnsmasq.leases file existed.

I then rebooted FTL with systemctl restart pihole-FTL followed by systemctl status pihole-FTL which returned

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated; vendor preset: enabled)
   Active: active (exited) since Mon 2020-10-19 17:12:42 EDT; 3s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 11380 ExecStop=/etc/init.d/pihole-FTL stop (code=exited, status=0/SUCCESS)
  Process: 11385 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)

Oct 19 17:12:41 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Oct 19 17:12:41 raspberrypi pihole-FTL[11385]: Not running
Oct 19 17:12:41 raspberrypi su[11403]: Successful su for pihole by root
Oct 19 17:12:41 raspberrypi su[11403]: + ??? root:pihole
Oct 19 17:12:41 raspberrypi su[11403]: pam_unix(su:session): session opened for user pihole b
Oct 19 17:12:42 raspberrypi pihole-FTL[11385]: FTL started!
Oct 19 17:12:42 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

and pihole status showed

  [✓] DNS service is running
  [✓] Pi-hole blocking is Enabled

This seems to have resolved my issue!

Delirium · October 19, 2020, 11:15pm

I got the similar issue with Pi-hole on Ubuntu Server 20.04 after upgrade!
In my case systemctl status pihole-FTL didn't told anything about dnsmasq.
Your "investigation" was very useful for me)

service dnsmasq status

dnsmasq: cannot access /etc/dnsmasq.d/lxd: No such file or directory

Then I found this and now it seems my issue is solved too!

Thank you!

Bucking_Horn · October 20, 2020, 6:48am

That is not a file Pi-hole would use by default.
Instead, it is one of dnsmasq's default locations for creating the leases file, so the existence of that file in that location would normally indicate a separate dnsmasq instance running.

Pi-hole's embedded pihole-FTL (its own tailored version of dnsmasq) would use /etc/pihole/dhcp.leases, if you enabled its DHCP server. Your current configuration may cause future troubles if you ever decide to activate it.

We should check your dnsmasq configuration for 3rd party additions.
Please post the output of the following command:

grep -nRv '^#\|^$' /etc/dnsmasq.*

noads · October 20, 2020, 2:57pm

Hm okay got it, thanks.

grep -nRv '^#\|^$' /etc/dnsmasq.*

gives

/etc/dnsmasq.conf:1:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:1:conf-dir=/etc/dnsmasq.d

/etc/dnsmasq.d/01-pihole.conf:21:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:22:addn-hosts=/etc/pihole/custom.list
/etc/dnsmasq.d/01-pihole.conf:25:localise-queries
/etc/dnsmasq.d/01-pihole.conf:28:no-resolv
/etc/dnsmasq.d/01-pihole.conf:32:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:34:log-queries
/etc/dnsmasq.d/01-pihole.conf:35:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:37:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:39:log-async
/etc/dnsmasq.d/01-pihole.conf:40:server=8.8.8.8
/etc/dnsmasq.d/01-pihole.conf:41:server=8.8.4.4
/etc/dnsmasq.d/01-pihole.conf:42:interface=wlan0
/etc/dnsmasq.d/01-pihole.conf:43:server=/use-application-dns.net/

/etc/dnsmasq.d/googadget-dnsmasq.conf:1:interface=usb0
/etc/dnsmasq.d/googadget-dnsmasq.conf:2:dhcp-range=192.168.11.50,192.168.11.100,255.255.255.0,2h
/etc/dnsmasq.d/googadget-dnsmasq.conf:3:dhcp-option=3
/etc/dnsmasq.d/googadget-dnsmasq.conf:4:dhcp-option=6

For context, I am using a Pi that came in a Google kit to make an internet speaker. I didn't use a clean OS install so perhaps that could be where some of this is coming from.

noads · October 20, 2020, 3:51pm

Glad you found it useful!

Bucking_Horn · October 20, 2020, 5:02pm

I've added some line breaks to your output, to separate the different files.

googadget-dnsmasq.conf is not a file that Pi-hole creates, so I assume it's from your earlier Google kit setup. Seems that it tried to turn your RPi into an access point.

Are you still using that Google kit software?

It's likely that came with its own dnsmasq, which may interfere with Pi-hole if still active.
Is that still present

which dnsmasq
sudo dpkg -s dnsmasq

or active?

sudo systemctl status --full --no-pager dnsmasq

noads · October 20, 2020, 5:17pm

I am no longer using the Google kit, so if anything needs to be removed I can do that. Appreciate all your input on this. Seems to me it is present and inactive?

which dnsmasq
/usr/sbin/dnsmasq

sudo dpkg -s dnsmasq
Package: dnsmasq
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 72
Maintainer: Simon Kelley <simon@thekelleys.org.uk>
Architecture: all
Version: 2.76-5+rpt1+deb9u1
Depends: netbase, dnsmasq-base (>= 2.76-5+rpt1+deb9u1), init-system-helpers (>= 1.18~)
Suggests: resolvconf
Conflicts: resolvconf (<< 1.15)
Conffiles:
 /etc/init.d/dnsmasq cb646f2b38d1477c2f470550621a0100
 /etc/default/dnsmasq 8528b9b07acf4cbac231eb21dd3d262c
 /etc/dnsmasq.conf 1a21048f8d8177af06e081a256a8ffe7
 /etc/resolvconf/update.d/dnsmasq 79d449fe3b873444952bc1192bb53f0c
 /etc/insserv.conf.d/dnsmasq 530a424ac064ea9d86f235d12ecc227a
Description: Small caching DNS proxy and DHCP/TFTP server
 Dnsmasq is a lightweight, easy to configure, DNS forwarder and DHCP
 server. It is designed to provide DNS and optionally, DHCP, to a
 small network. It can serve the names of local machines which are
 not in the global DNS. The DHCP server integrates with the DNS
 server and allows machines with DHCP-allocated addresses
 to appear in the DNS with names configured either in each host or
 in a central configuration file. Dnsmasq supports static and dynamic
 DHCP leases and BOOTP/TFTP for network booting of diskless machines.

sudo systemctl status --full --no-pager dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
   Loaded: loaded (/lib/systemd/system/dnsmasq.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Bucking_Horn · October 20, 2020, 5:37pm

It's good dnsmasq is inactive - that means it's currently not interfering with Pi-hole.

It still could be restarted on rebooting your machine, so it's probably best to remove it completely:

sudo apt-get purge dnsmasq

As you don't use the Google kit anymore, you could just delete /etc/dnsmasq.d/googadget-dnsmasq.conf.
If you want to backup it instead, don't keep it in the dnsmasq.d/ folder by just renaming it - move it away, e.g. to your home directory.

Then restart Pi-hole by running:

pihole restartdns

As to what happened:
That left-over configuration under dnsmasq.d/ instructed pihole-FTL to start its DHCP server and propagate itself as router (option 3) and DNS server (option 6) for devices on usb0.
In doing so, Pi-hole also tried to access the standard lease file, which likely was created by your Google kit sometime before, hence the permission mismatch.

Removing the configuration file will allow Pi-hole to operate as expected.
Purging dnsmasq from your system will ensure pihole-FTL and dnsmasq won't fight over port 53.

Your own take at setting permissions for that non-standard Pi-hole file may have worked for the moment, but it didn't address the root cause at all.

Bucking_Horn · October 20, 2020, 5:41pm

Above will likely be true for you as well, Delirium, as your system also seems to run (or at least have) dnsmasq in additon to Pi-hole.

If that's still an issue, please consider opening a new topic - unless you also ran a Google kit before.

noads · October 20, 2020, 5:51pm

Ah beautiful. Thanks for the detailed explanation and all your help!

Delirium · October 20, 2020, 8:00pm

Thanks, my system runs well
dnsmasq had State: degraded - removed it completely, as you suggested.
About /etc/dnsmasq.d/lxd - it must be some kind of left-over configuration, don't mind where it comes from.
Issue solved. Thanks for your help!

system · November 10, 2020, 8:00pm

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