Please,
Mask the service again, reboot the system and generate a new Pi-hole Debug Log.
Done.
Your debug token is: https://tricorder.pi-hole.net/wdbBphKO/
Da es gestern schon spät gewesen ist, wollte ich nochmal fragen ob ihr noch eine Idee habt? Konntet ihr aus dem zweiten Log was erkennen?
Since it was already late yesterday, I wanted to ask again if you still have an idea? Could you recognize something from the second log?
Regards
Das Debug Log zeigt erwartungsgemäß, dass unbounds Ports frei sind.
Deine /etc/unbound/unbound.conf*-Dateien liefern dabei weder einen Hinweis auf eine Remote-Control-Aktivierung/Port 8953 noch auf den minütlichen Neustart.
Was steht denn in der Datei:
sudo cat /etc/default/unbound
1 Like
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!