Die Datei gibt es bei mir garnicht bzw. wurde nicht angelegt beim Install 
Wie sollte der Inhalt sein von der Datei? Nicht das der Fehler dadurch entsteht?
Wir suchen nach Erklärungen für Deine folgenden beiden Beobachtungen (die erst einmal beide nichts mit Pi-hole zu tun haben):
a) unbound aktiviert beim Starten die Remote-Control-Unterstützung und bindet Port 8953, obwohl diese laut unbound-Dokumentation standardmässig deaktiviert ist.
b) unbound startet minütlich neu
Wie wir zu a) bereits herausgefunden haben, wird remote-control nicht über Deine /etc/unbound/unbound.conf*-Dateien gesetzt.
Auf Deinem OS startet die unbound-Service-Unit unbound über
Dabei können in $DAEMON_OPTS weitere Parameter übergeben werden.
Innerhalb der Service-Unit wiederum könnte diese Umgebungsvariable aus der erwähnten Datei gesetzt werden:
Da diese Datei bei Dir nicht existiert, bin ich ratlos, woher diese Einstellung kommt.
Es bleibt zu vermuten, dass die unbound-Version für Dein OS explizit mit Remote-Control-Unterstützung kompiliert wurde.
In der Tat ist dies wohl in der Vergangenheit ab und an für Debian erfolgt, sollte aber zwischenzeitlich wieder zurückgebaut sein - siehe z.B. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991017.
Eventuell ist diese Änderung aber in Deinem OS-Release (Debian 11 laut Debug Log) noch nicht angekommen.
Es ist auch nach wie vor unklar, ob diese unerwartete Aktivierung von Remote-Control zu Deinem Fehlerbild von minütlichen Neustarts beiträgt.
Da wir aber bislang keine entsprechende Konfiguration gefunden haben, könntest Du versuchen, remote-control in Deiner /etc/unbound/unbound.conf.d/pi-hole.conf abzuschalten.
Dazu müsstest Du dieser Datei folgende Definition hinzufügen:
# Disable remote-control
remote-control:
control-enable: no
Danach sollte unbound neu gestartet werden:
sudo systemctl restart unbound.service
Treten danach die minütlichen Neustarts noch auf?
1 Like
Vielen Dank für die Ausführliche erklärung und das ihr/ du noch am Ball bist und mir helfen möchtest.
Wenn es ein BUG im OS ist wäre natürlich ziemlich doof wobei es dann nicht nur bei mir auftreten dürfte oder?
Mein Pi habe ich vor ein paar Wochen neu aufgesetzt über den offiziellen Pi Imager. Updates werden regelmäßig auch eingespielt. Also sollte das Repo doch eigentlich ganz aktuell sein 
Ich habe deinen Tipp gerade umgesetzte mit dem disable remote control in der pihole config.
Leider startet jetzt der unbound.service nicht mehr mit dem Eintrag:
Edit: unbound-checkconfig sagt es ist ein Syntax Fehler.
remote-control sollte ein neuer "Abschnitt" sein und nicht innerhalb von server stehen.
Pack remote-control und control-enable mal ganz ans Ende der Datei. Und rücke den Unterpunkt ein.
1 Like
Nachdem ich den Eintrag nach unten gesetzt habe in der config läuft der unbound.service wieder. Der Fehler mit dem Port 8953 ist dadurch auch verschwunden aber der service startet immer noch minütlich neu. Also hängt die Port Geschichte nicht mit dem restart zusammen. Zum verrückt werden werden 
.
Ich habe gerade einen reboot gemacht in der Hoffnung das es was bringt leider auch ohne Erfolg. Was mich irgendwie stutzig macht das der unbound.service über systemctl disable unbound deaktivert werden kann aber trotzdem weiter automatisch startet und das sogar weiterhin wenn der service per systemcrl stop unbound gestoppt wird.
Nicht das es ein Bug in systemd ist oder ggf. in der unbound.dervice Datei?
Debian 11 verwendet noch einen speziellen Patch um remote-control standarmäßig zu aktivieren. Erst in Bookworm ist der raus.
https://sources.debian.org/patches/unbound/1.17.1-2/
P.S. Bullseye backport nutzt auch schon die neue Version 1.17.2. - die könntest du mal spaßeshalber ausprobieren: Debian -- Informationen über Paket unbound in bullseye-backports
2 Likes
Hallo @yubiuser danke für die Hinweise. Das Problem mit der remote control konnte wir eben über die den zusätzlichen Eintrag
# Disable remote-control
remote-control:
control-enable: no
in der pihole.conf beheben. Zumindest erscheint jetzt keine Fehlermeldung mehr das der Port belegt ist.
Problematisch ist das der unbound.service weiterhin jede minute neu startet egal was man macht. Denkst du das es durch die Backport Version ggf. behoben sein kann?
Da wir die Ursache überhaupt noch nicht gefunden habe und noch recht ratlos sind was überhaupt bei dir passiert wäre es zumindest einen Versuch wert....
Kannst du mir kurz erklären wie ich die Backport Version installiert bekomme?
Ich hatte es vor ein paar Jahren mal gemacht kann mich nur noch schwach erinnern das in irgendeiner source datei was geändert werden muss ?
Würde es dann testen nachdem ich ein aktuelles Image gezogen habe von der SSD am Pi.
Schau mal: Instructions
deb http://deb.debian.org/debian bullseye-backports main in /etc/apt/sources.list aufnehmen, dann apt update
Und dann apt install -t bullseye-backports unbound
1 Like
Werde es heute leider nicht mehr schaffen da ich Morgen ziemlich früh raus muss. Melde mich morgen mit dem Ergebnis zurück.
Vielen Dank euch beiden für den Support @Bucking_Horn @yubiuser wünsche einen schönen Rest Abend!
Hallo zusammen, nun habe ich die Version aus den Backports installiert (unbound ist schon die neueste Version (1.17.1-2~bpo11+1).
) und einen reboot gemacht. Geändert hat es leider nichts an dem Verhalten der unbound.service startet weiterhin jede Minute neu. Schade hatte echt Hoffnung das es die Lösung ist 
.
Ich habe gerade gesehen das in etc/init.d eine Datei bzw. Skript unbound liegt. Könnte das Verhalten ggf. mit diesem Skript zusammenhängen?
Hier der Inhalt:
#!/bin/sh
### BEGIN INIT INFO
# Provides: unbound
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Validating, recursive, and caching DNS resolver
### END INIT INFO
# pidfile: /run/unbound.pid
NAME="unbound"
DESC="DNS server"
DAEMON="/usr/sbin/unbound"
PIDFILE="/run/unbound.pid"
HELPER="/usr/libexec/unbound-helper"
test -x $DAEMON || exit 0
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
. /lib/lsb/init-functions
# Override this variable by editing or creating /etc/default/unbound.
DAEMON_OPTS=""
if [ -f /etc/default/unbound ]; then
. /etc/default/unbound
fi
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$NAME"
$HELPER chroot_setup
$HELPER root_trust_anchor_update 2>&1 | tee /dev/fd/2 | logger -p daemon.info -t unbound
if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
$HELPER resolvconf_start
log_end_msg 0
else
log_end_msg 1
fi
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
if start-stop-daemon --stop --quiet --oknodo --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5; then
$HELPER resolvconf_stop
$HELPER chroot_teardown
log_end_msg 0
else
log_end_msg 1
fi
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
start-stop-daemon --stop --quiet --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5
$HELPER resolvconf_stop
if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
$HELPER chroot_setup
$HELPER resolvconf_start
log_end_msg 0
else
log_end_msg 1
fi
;;
reload)
log_daemon_msg "Reloading $DESC" "$NAME"
if start-stop-daemon --stop --pidfile $PIDFILE --name $NAME --signal 1; then
$HELPER chroot_setup
log_end_msg 0
else
log_end_msg 1
fi
;;
status)
status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|restart|status|reload|force-reload}" >&2
exit 1
;;
esac
exit 0
Edit: Habe das Skript unbenannt in old.unbound und ein reboot gemacht. Fehler besteht weiterhin -.-
Ich habe leider keine Gute Idee mehr.
I'm going to ping @deHakkelaar because they have a deep linux knowledge and usually dig deep to find the cause of issues.
1 Like
Das ist sehr nett von dir vielen Dank!
Gibt es irgendeinen Hinweis auf einen unbound-Fehler?
journalctl -u unbound.service
Falls nicht, wäre das ein weiterer Hinweis auf einen kontrollierten Stop.
Um herauszufinden, welcher Prozess unbound stoppt, könntest Du die Verfahren aus Unbound frequent restarts - #121 by jpgpi250 nutzen - jpgpi hat das ganz gut zusammengefasst (allerdings auf Englisch).
In eben diesem Topic wurde vermutet (aber nie zweifelsfrei nachgewiesen), dass IPv6-RAs des Routers involviert sind und ggf. von Netzwerkprozessen zum Anlass für einen Neustart genommen werden. Da Router RAs regelmässig aussenden, könnte das u.U. auch eine mögliche Erklärung für die doch sehr regelmässigen Abstände sein, in denen Dein unbound neu startet.
Allerdings senden Router diese Router Advertisements für gewöhnlich nicht in nur einminütigen Abständen.
Immerhin könntest Du überprüfen, ob RAs minütlich bei Dir auftauchen:
Dazu kannst Du radvdump verwenden:
sudo apt install radvdump
sudo radvdump
Dann eine Weile warten, bis die RAs Ihren Bildschirm füllen (das kann ein paar Minuten dauern) und schauen, ob sich das jede Minute wiederholt.
1 Like
Hallo zusammen, ich konnte tatsächlich das Problem nach vielen Stunden der Suche vorhin finden. Glücklicherweise ist es was ganz banales gewesen was durch mich sowie ein scheinbar falsches Tutorial ausgelöst wurde. In diesem Tutorial habe ich ein kleinen Teil genutzt um unbound automatisch zu aktualisieren. Und dort war der Fehler begraben.
Die Lösung habe ich im Debian Forum wo ich mir parallel Unterstützung gesucht hatte mit dem Verdacht das es an systemd liegt gerade eben beschrieben.
Ich poste hier einen meinen Auszug zur Ursache und bedanke mich mit einem dicken DANKESCHÖN für eure Unterstützung und bitte zu entschuldige das es am User/Blödheit bzw. am falschen Tutorial gelegen hat.
1 Like
I believe some people noticed the root.hints download remarks in the official guide and/or in the unbound config file itself and became a bit overzealous with updating.
They haven't changed allot over the last decade or so and there are a total of 26 addresses (if also have IPv6 support upstream):
pi@ph5b:~ $ awk '/ A / {print $4}' /usr/share/dns/root.hints
198.41.0.4
199.9.14.201
192.33.4.12
199.7.91.13
192.203.230.10
192.5.5.241
192.112.36.4
198.97.190.53
192.36.148.17
192.58.128.30
193.0.14.129
199.7.83.42
202.12.27.33
pi@ph5b:~ $ awk '/ AAAA / {print $4}' /usr/share/dns/root.hints
2001:503:ba3e::2:30
2001:500:200::b
2001:500:2::c
2001:500:2d::d
2001:500:a8::e
2001:500:2f::f
2001:500:12::d0d
2001:500:1::53
2001:7fe::53
2001:503:c27::2:30
2001:7fd::1
2001:500:9f::42
2001:dc3::35
Its sufficient to run sudo apt update && sudo apt upgrade every couple of months or so to also update the root.hints which are installed automatically with the unbound package:
pi@ph5b:~ $ apt depends unbound
[..]
Depends: dns-root-data
pi@ph5b:~ $ dpkg -L dns-root-data
[..]
/usr/share/dns/root.hints
pi@ph5b:~ $ head /usr/share/dns/root.hints
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
Even if you wouldn't update the root.hints, I suspect you wont experience any troubles for the next couple of decades or so.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.