Have to "pihole restartdns" after reboot

Can you cat /etc/dnsmasq.d/01-pihole.conf?

root@fr0sh-pi:~# cat /etc/dnsmasq.d/01-pihole.conf
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Dnsmasq config for Pi-hole's FTLDNS
#
# This file is copyright under the latest version of the EUPL.# Please see LICENSE file for your rights under this license.

###############################################################################
#      FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.      #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#        IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN:          #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#        ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE           #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #
###############################################################################

addn-hosts=/etc/pihole/local.list
addn-hosts=/etc/pihole/custom.list


localise-queries


no-resolv



cache-size=10000

log-queries
log-facility=/var/log/pihole.log

local-ttl=2

log-async






server=127.0.0.1#5353
dnssec
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

local-service
server=/fritz.box/192.168.178.1
server=/178.168.192.in-addr.arpa/192.168.178.1
server=/use-application-dns.net/
root@fr0sh-pi:~#

Ah, looks like that's been updated to use:

local-service

Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server. This option only has effect if there are no --interface , --except-interface , --listen-address or --auth-server options. It is intended to be set as a default on installation, to allow unconfigured installations to be useful but also safe from being used for DNS amplification attacks.

So if the interface is not online when FTL starts, then it does not know that it's a valid subnet to answer questions for.

1 Like

This would be eth0 in my case.
(I did not check VPN after a reboot yet...)

So is there a way to start FTL a bit "slower"?

See my previous answer to the question.

You can probably do something like wait for the interface to come up properly, but I just have the following in /etc/rc.local on my pi zero which takes a bit longer for its usb network to initialize.

sleep 15
pihole restartdns

1 Like

rc.local is deprecated on DietPi.
So i placed a script "wait.sh" in "/var/lib/dietpi/postboot.d/" and made it +x.

#!/bin/bash
sleep 10
pihole restartdns

After testing two times it seems to be working fine.

Thanks a lot!

1 Like

You can open a feature request for this and we can add a setting for it. This is really an easy task and the code can be implemented and tested within minutes.

@Rico_Lino @DL6ER
Easiest solution is to place an override config that makes pihole-FTL wait for WireGuard:

mkdir -p /etc/systemd/system/pihole-FTL.service.d
echo -e '[Unit]\nAfter=wg-quick@wg0.service' > /etc/systemd/system/pihole-FTL.service.d/wait_for_wireguard.conf

But the current Pi-hole v5 installer errors out when it finds any override config, hence this will break pihole -up for now... I hope I can convince everyone to drop that behaviour, as we have an exact fine reason here to use them :wink:. EDIT: Ah nope sorry, this has not been merged: Full systemd support by Kiskae · Pull Request #2900 · pi-hole/pi-hole · GitHub So no issue at all with the above override config :+1:.


And the iptables forwarding rules are required for VPN clients to access anything else then the VPN server itself (local network or internet). If indeed the VPN is only to enable Pi-hole for mobile clients, then indeed those rules can and should be dropped, same for sysctl net.ipv4.ip_forward which is as well not required then.

1 Like

@Rico_Lino

You could also just create a new file like 02-wireguard.conf in /etc/dnsmasq.d/ with interface=wg0.

This worked for me to sustain a reboot and have pihole to listen on eth0 and wg0 with the setting Listen all interfaces (not Listen on all interfaces, permit all origins)

If you do that then expect things to break when you try to use any interface that isn't wg0.

Thanks for the tip. Then I'll go with the solution @MichaIng provided.

As suggested above I created a feature request for an optional pihole startup delay.

@DL6ER was very kind

1 Like

Dirty fix. The problem with such unconditional delays is that one can never be sure that it is enough in every case and/or if it is unnecessary long in most cases. I would always go with a conditional delay, so things start as fast as possible but as late as required. But great for inexperienced users who simply need to get things working quickly :+1: .

So where's your solution?

Posted above for this particular case: Have to "pihole restartdns" after reboot - #21 by MichaIng
However indeed reasons to delay pihole-FTL for and service handlers/init system can vary, so I cannot imagine any Pi-hole provided solution for this, without adding a tons of checks and options.

The service could contain Required-Start: $network, probably there is even an equivalent for the systemd network-online.target (not supported on older systemd version, e.g. Debian Jessie). But neither network.target nor network-online.target guarantee that all network interfaces have been fully configured.

So while the above could reduce the chance for such issue slightly, it is finally something that the admin needs to add manually if required for the particular network setup.

So there aren't any other options besides a "dirty fix" for "inexperienced users"?

Nothing I can think of. You can try to implement all possible solutions, or a GUI for service ordering based on init system. But in special cases there will be always individual solutions required, not everything is, can be or even should be under control of Pi-hole, IMO.

"dirty fix" btw does not mean that I dislike the implementation. As said it is great to get things working quickly. It is just not something that I would keep as long-term solution for my server, for the mentioned reasons.

The dirty fix is now available in the regular beta branch and will be shipped with Pi-hole v5.0

6 Likes