Dietpi: Update process stops unbound and then fails downloading stuff

[omnidepp]

I'm using DietPi with Pihole and an unbound-setup for DNS over TLS.

Required Information

• DietPi version | 6.28
• Distro version | bullsey
• Kernel version | Linux PiHole 4.19.97+ #1294
• SBC model | RP Zero
• Power supply used | 5BV 1A

Steps to reproduce

Run DietPi Update
This will stop a number of services including unbound.
Once unbound is stopped, DNS-resolution does not work any more (obviously) and further steps in the update process fail.

Expected behaviour

Don't globally stop unbound when not absolutely needed :-)

[Joulinar]

Hi,

many thanks for your report. Yes there are ways to exclude services from being restarted during software installations. This can be done by running dietpi-services and mark your service as excluded. One example how it will looks like for lighttpd

┌─────────────────────────────────────────────────┤ DietPi-Services ├──────────────────────────────────────────────────┐
│ Please select an option for lighttpd:                                                                                │
│                                                                                                                      │
│                                               ●─ Service Control ───────────────────────────●                        │
│                       State                   : [active]                                                             │
│                       Mode                    : [DietPi controlled]                                                  │
│                       Include/Exclude         : [excluded]                                                           │
│                       Status                  : Display systemd status log                                           │
│                       Edit                    : [/lib/systemd/system/lighttpd.service]                               │

another way is to edit the respective config file directly

nano /boot/dietpi/.dietpi-services_include_exclude

add your service to the end like this

root@DietPi322:~# cat /boot/dietpi/.dietpi-services_include_exclude
# DietPi-Services Include/Exclude configuration

# Include custom service (Use '+ servicename' without the comments to enable DietPi control of that service)
#       Once completed, for DietPi to control the service, please run the following command, without quotes (')
#       'dietpi-services dietpi_controlled'
#+ myservice1
#+ myservice2

# Exclude DietPi from controlling known services (Use '- servicename' without the comments to disable DietPi control for that service)
#       The service will be in disabled form, and, you can start and stop it manually
#- cron
#- transmission-daemon

- lighttpd

[BerndKohl]

Interesting, did not know that.
Question: Would e.g. setting pi-hole to be excluded mean, that it would NOT get startet automatically on system boot and stopped on shutdown? Or does this only stand for service stopping/restarting during a software update?
And what if this update does include the service set to be excluded?

[Joulinar]

Nope it should not have any impact on system boot behaviour. This affects starts/stops/restarts during DietPi-Software installs, DietPi-Update, DietPi-Backup and similar maintenance tasks only.

Regarding PiHole. I never faced any issues having it managed by DietPi becasue if you switch off PiHole service pihole-FTL.service, your system will use DNS settings that are defined on network config. I did a small test for you 😜

1. PiHole is running and DNS server is pointing to 127.0.0.1

root@DietPi4:/etc# cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

1. PiHole stopped and DNS server is pointing to 1.1.1.1 & 1.0.0.1

root@DietPi4:/etc# systemctl stop pihole-FTL.service
root@DietPi4:/etc# cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 1.1.1.1
nameserver 1.0.0.1

1. PiHole restarted and DNS server is pointing to 127.0.0.1 again

root@DietPi4:/etc# systemctl start pihole-FTL.service
root@DietPi4:/etc# cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
root@DietPi4:/etc#

[BerndKohl]

Thank you @Joulinar. I did so far not have an issue with pi-hole during updates, this was just used as an example. But anyhow, good to know.
Your answer did raise another question though: Is this the default behaviour?
I use pi-hole as my primary DNS server in my network. All clients get their IP and DNS settings from my router (which is NOT pi-hole). So if pi-hole fails (during update for instance) my clients should automatically use the router as secondary DNS server automatically (this does not always seem to work very well) - but this is completely off topic now - sorry.

[Joulinar]

Hi,

the scenario I described above is applicable for the host running PiHole themselves. It will not have any impact to clients. Your clients always use the given DNS config. Means, if you have configured a 2nd DNS Server, it will be used if 1st one is not reachable or answering.

[MichaIng]

@omnidepp @BerndKohl @Joulinar
DNS services are by default excluded from DietPi-Services control, so they should stay active during DietPi-Update and DietPi-Software processing. They could be added manually as @Joulinar described above, however of course no-one wants to break it's own DNS before running installs or upgrades. So not sure why unbound was handled, but at least it is not done by DietPi scripts, probably as part of an unbound APT package upgrade, although bad the it does not re-enable itself then 🤔.

Pi-hole v4 indeed forces the system to use itself as DNS resolver. I was not aware that stopping the service restores previous defaults, to it would be possible do handle it by DietPi-Services. However better not touch this, as we do not know whether the previous entries are still valid or not.

Btw: Pi-hold v5 leaves /etc/resolv.conf untouched. Hence when one wants the server itself to resolve through Pi-hole, it must be edited manually. Generally makes sense since the service is often used as server only and one does not use it to browse the web where ad blocking makes sense.