Thats why I'm trying to bind dnsmasq to all 0.0.0.0.
If network is not ready, dnsmasq will not start.
Thats true but it has not been proven yet that networking started too late as dnsmasq does start listening on for example the loopback interface (which also requires networking).
Only a suspicion that one of the interfaces comes up a bit late.
EDIT: Ohw and as a last resort, you could alter dnsmasq's systemd unit file to wait for this interface to come up.
But to be honest, I have never done this before.
this is my netstat result after after setting listening address to 0.0.0.0,::
bukka@orangepizero:~$ sudo netstat -nltup | grep "Proto|:53 "
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
bukka@orangepizero:
absolutely blank. probably because dnsmasq failed to start.
sudo systemctl status dnsmasq
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Drop-In: /run/systemd/generator/dnsmasq.service.d
└─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
/etc/systemd/system/dnsmasq.service.d
└─override.conf
Active: failed (Result: exit-code) since Thu 2018-02-08 16:54:21 IST; 23s ago
Process: 1673 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=2)
Process: 1670 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Feb 08 16:54:21 orangepizero systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Feb 08 16:54:21 orangepizero dnsmasq[1670]: dnsmasq: syntax check OK.
Feb 08 16:54:21 orangepizero dnsmasq[1673]: dnsmasq: failed to create listening socket for ::: Address alr
Feb 08 16:54:21 orangepizero systemd[1]: dnsmasq.service: Control process exited, code=exited status=2
Feb 08 16:54:21 orangepizero systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS serv
Feb 08 16:54:21 orangepizero systemd[1]: dnsmasq.service: Unit entered failed state.
Feb 08 16:54:21 orangepizero systemd[1]: dnsmasq.service: Failed with result 'exit-code
hashed out listen-address and set the interface as Jeroen1 mentioned:
interface=eth0
except-interface=wlan0
in this case, dnsmasq again goes back to listening to loopback only.
repeated above with listen-address set to 0.0.0.0,::
dnsmasq failed again.
seems uncommenting the listen-address always cause dnsmasq to fail, no matter what value i put down.
Try ipv4 only first without the ipv6 bit "::"
listen-address=0.0.0.0
Could you post status output again as bits didn't get copied over when pasting here ?
Try to enclose the output with the "Preformated text" buttons while editing.
Oops sorry, you omitted the "-l" argument with the status command:
sudo systemctl status dnsmasq -l
Could you try again please ?
EDIT: if its fails again with something like "address already in use",
you might want to disable systemd starting dnsmasq at boot with below one:
sudo systemctl disable dnsmasq
Reboot and run the netstat and status commands again to check if dnsmasq really didnt start.
If it did start, it feels like something else is booting up dnsmasq with the undesired listening behaviour.
To enable again:
sudo systemctl enable dnsmasq
EDIT2: if after reboot, you run below one, you'll see some more details how dnsmasq was called upon:
sudo ps -aux | grep dnsmasq
bukka@orangepizero:~$ sudo systemctl status dnsmasq -l
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Drop-In: /run/systemd/generator/dnsmasq.service.d
└─50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
/etc/systemd/system/dnsmasq.service.d
└─override.conf
Active: failed (Result: exit-code) since Thu 2018-02-08 17:38:07 IST; 2min 2s ago
Process: 603 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=1/FAILURE)
Feb 08 17:38:06 orangepizero systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Feb 08 17:38:06 orangepizero dnsmasq[603]: dnsmasq: extraneous parameter at line 4 of /etc/dnsmasq.d/netwo
Feb 08 17:38:07 orangepizero systemd[1]: dnsmasq.service: Control process exited, code=exited status=1
Feb 08 17:38:07 orangepizero systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS serv
Feb 08 17:38:07 orangepizero systemd[1]: dnsmasq.service: Unit entered failed state.
Feb 08 17:38:07 orangepizero systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Warning: dnsmasq.service changed on disk. Run 'systemctl daemon-reload' to reload units.
listen-address=0.0.0.0
should i try disabling the dhcp?
well, i have removed the network-manager file from /etc/dnsmasq.d
there was only one line which was not hashed at the end of that file which read something like
binding-address=
and voila
bukka@orangepizero:/etc/dnsmasq.d$ sudo netstat -nltup | grep "Proto|:53 "
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 736/dnsmasq
tcp6 0 0 :::53 :::* LISTEN 736/dnsmasq
udp 0 0 0.0.0.0:53 0.0.0.0:* 736/dnsmasq
udp6 0 0 :::53 :::* 736/dnsmasq
is it safe for dnsmasq to listen to all ips?
I cant see what file is mentioned because the line is cut off.
What files are in that folder ?
ls -al /etc/dnsmasq.d
And what is on line 4 in that file ?
sed '4q;d' /etc/dnsmasq.d/netwo*
Great find !!!
Yes is safe as its the default listening behaviour for my Raspbian distribution.
Cheers !!!
ls -al /etc/dnsmasq.d
total 16
drwxr-xr-x 2 root root 4096 Feb 8 17:52 .
drwxr-xr-x 103 root root 4096 Feb 8 17:53 ..
-rw-r--r-- 1 root root 1520 Feb 8 17:50 01-pihole.conf
-rw-r--r-- 1 root root 0 Jan 27 06:17 03-pihole-wildcard.conf
-rw-r--r-- 1 root root 211 Oct 23 12:02 README
the network-manager file is removed. dont remember what was written exactly.
thank you so much guys for putting up with a noob like me, especially deHakkelaar. it has been quite a tedious process to troubleshoot this problem but with your help everything worked out well in the end.
Cheers!!
2 Likes
I experienced this recently, and narrowed down the issue for myself. In my case, I use docker-based pihole. I had /etc/pihole/pihole-FTL.conf in docker volumes list, and also /etc/pihole already listed. I removed specific /etc/pihole/pihole-FTL.conf mapping and it started up. Although I'm unsure why should this be an issue for underlying docker platform, so silly to not notice this earlier.