unbound.service startet jede minute neu ohne Fehlermeldung?

[Nastra]

Hallo zusammen,

ich habe ein Problem mit einem systemd service und hoffe von euch hat einer eine Idee? Und zwar habe ich mir zusätzlich zu meinem pi-hole die Software Unbound installiert. Anfänglich hatte ich ein Problem mit einem belegten Port was aber durch Hilfe der Jungs im pi-hole Forum behoben werden konnte.

Leider musste ich zusätzlich feststellen das der unbound.service sich immer genau nach einer Minute selbständig neu startet. In der Praxis ist es bisher nicht bemerkbar aber schön ist was anderes. Ich habe die Problematik ebenfalls im pi-hole Forum kommuniziert da ich bisher davon ausgegangen bin das es ein Problem von unbound bzw. pi-hole ist.

Dort habe ich auch durch Moderatoren und Entwickler bisher guten Support erhalten was die Fehleranalyse Softwareseitig angeht. Bisher konnte Softwareseitig kein Fehler festgestellt werden.

Leider ist man dort mittlerweile auch etwas Ratlos warum sich der service immer wieder neu startet. Ich selber könnte mir mittlerweile auch vorstellen das es vielleicht ein systemd bug ist. Leider fehlt mir hier das Know How um das Problem zu Identifizieren. Daher hoffe ich ggf. hier auf Hilfe um das Problem zu finden.

Das verhalten vom service ist zusätzlich zu dem 1 Minütigen neu start ebenfalls komisch, da man den Service mit:
sudo systemctl disable unbound.service bzw. sudo systemctl stop unbound.service nicht deaktivieren oder stoppen kann. Es kommt zwar die Bestätigung aber der Service startet weiterhin jede Minute neu. Im journalctl sowie im Status sind keine Fehler gelistet.

Die einzige Möglichkeit den Service Mundtot zu machen ist über: sudo systemctl mask unbound.service

Screen von der Dauerschleife:
https://ibb.co/KNPdKht

Infos zum System:
System...............: Debian GNU/Linux 11 (bullseye)
Kernel...............: Linux 6.1.21-v8+

Was wurde noch geprüft:
cronjobs: keine vorhanden auf dem System
systemd.timer: keiner vorhanden der unbound.service triggert
unbound: neuste Version aus den Backports auf Rat eines Entwicklers Installiert
unbound.service / unit gelöscht und neu angelegt

Ich hoffe das genügt für einen ersten Einblick in die Problematik meiner 1 minütigen Dauerschleife .-)
Wie gesagt ich gehe mittlerweile davon aus das der Fehler irgendwie mit systemd zusammenhängt statt der unbound Software daher würde ich mich sehr über eure Unterstützung freuen.

Anbei noch der Link zu meinem Thread im pi-hole Forum mit weiteren Informationen bzw. ein paar Screenshots.
https://discourse.pi-hole.net/t/unbound ... 3/62944/42
Ich hoffe das ist in Ordnung ansonsten bitte lösche liebe Mods.

Beste Grüße
Nastra

[chrbr]

Bei mir läuft unbound auf Bullseye ohne Probleme. Ich poste hier einfach mal meine Konfiguration. Dann kannst Du das mit deinen Dateien vergleichen. Mit den Screenshots tue ich mich etwas schwer.

unbound.conf

Code: Alles auswählen

server:
verbosity: 1
num-threads: 1
interface: 127.0.0.1
port: 53
cache-min-ttl: 60
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
use-systemd: yes
access-control: 127.0.0.0/8 allow
chroot: ""
use-syslog: yes
log-time-ascii: yes
log-queries: no
log-replies: yes
log-tag-queryreply: no
log-local-actions: no
log-servfail: yes
pidfile: "/var/run/unbound.pid"
prefetch: no
prefetch-key: no
include: "/etc/unbound/local-void.zones"
python:
dynlib:
remote-control:
control-enable: no

unbound.service

Code: Alles auswählen

[Unit]
Description=Unbound DNS server
Documentation=man:unbound(8)
After=network.target
Before=nss-lookup.target
Wants=nss-lookup.target

[Service]
Type=notify
Restart=on-failure
EnvironmentFile=-/etc/default/unbound
ExecStartPre=-/usr/lib/unbound/package-helper chroot_setup
ExecStartPre=-/usr/lib/unbound/package-helper root_trust_anchor_update
ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS
ExecStopPost=-/usr/lib/unbound/package-helper chroot_teardown
ExecReload=+/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

[chrbr]

Eins habe ich doch gesehen:

Code: Alles auswählen

/etc# systemctl status unbound.service
● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-05-17 11:04:32 CEST; 7h ago
       Docs: man:unbound(8)
    Process: 537 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 553 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
   Main PID: 556 (unbound)
      Tasks: 1 (limit: 9323)
     Memory: 23.8M
        CPU: 1.335s
     CGroup: /system.slice/unbound.service
             └─556 /usr/sbin/unbound -d -p

Unter "Loaded" steht bei dir "disabled".

[Nastra]

Vielen Dank!

Ich habe gerade deine unbound.conf sowie die Service Datei mit meiner verglichen. Die Service ist identisch. Sollte also passen.

Bei der unbound.conf steht bei mir was ganz anderes als bei dir:

Code: Alles auswählen

 # Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

Dafür habe ich aber unter unbound.conf.d eine pi-hole.conf mit folgendem Inhalt, bin mir nur nicht sicher wo der Unterschied genau ist. Wegen pi-hole ggf.?

Code: Alles auswählen

 server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m
    
    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10
    
    # Disable remote-control
    remote-control:
        control-enable: no

Der Hinweis von dir das im status disable steht ist vermutlich nur ein Zufall gewesen beim Screen erstellen. In der Praxis lässt der Service sich nicht deaktivieren. Hatte ich aber oben auch erwähnt. Er startet immer weiter neu auch wenn man disable und anschließend sudo systemctl stop unbound.service aufruft. Das ist ja das kuriose. Unbound Checkconf sagt mir auch alles in Ordnung.

Ich habe dein Config gerade testweise mal bei mir eingefügt und den Service neu gestartet aber dann kommt ein Fehler:
Unbound DNS server...
Mai 17 18:19:03 Gr-SHS-4 package-helper[5636]: /etc/unbound/unbound.conf:24: error: cannot open include file '/etc/unbound/local-void.zones': No such file or directory
Mai 17 18:19:03 Gr-SHS-4 package-helper[5636]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file

[chrbr]

Ich habe noch etwas. Im Beitrag Nastra May 16, 2023, 7:35pm 36 steht etwas wie
"Sync state ... with SysV init script"

Hast Du SysV Skripts bewusst aktiviert bzw verwendest Du den Mechanismus noch woanders?
Könntest Du zumindest für unbound den SysV Pfad deaktivieren?

Mit pi-hole kenne ich mich nicht aus. Deshalb stelle ich meine seltsamen Fragen.

[chrbr]

Ich habe dein Config gerade testweise mal bei mir eingefügt und den Service neu gestartet aber dann kommt ein Fehler:
Unbound DNS server...
Mai 17 18:19:03 Gr-SHS-4 package-helper[5636]: /etc/unbound/unbound.conf:24: error: cannot open include file '/etc/unbound/local-void.zones': No such file or directory

Entschuldigung, das hätte ich löschen sollen. Du kannst die Zeile einfach auskommentieren. Das Paket unbound void zones (der genaue Name ist mir gerade entfallen) sammelt von verschiedenen Webseiten Adressen von Add-Ware und anderem unerwünschten Kram. Denen werden in einer Datei local-void.zones wird sowas zugewiesen:

Code: Alles auswählen

/etc/unbound# tail local-void.zones
local-zone: "zy16eoat1w.com" static
local-zone: "zyban.1.p2l.info" static
local-zone: "zyban-store.shengen.ru" static
local-zone: "zyrtec.1.p2l.info" static
...

Die Adressen werden dann erst gar nicht aufgelöst.

[Nastra]

Ich habe noch etwas. Im Beitrag Nastra May 16, 2023, 7:35pm 36 steht etwas wie
"Sync state ... with SysV init script"

Hast Du SysV Skripts bewusst aktiviert bzw verwendest Du den Mechanismus noch woanders?
Könntest Du zumindest für unbound den SysV Pfad deaktivieren?

Mit pi-hole kenne ich mich nicht aus. Deshalb stelle ich meine seltsamen Fragen.

Ich habe das Skript nicht aktiviert. Ich vermute es wurde mit bzw. durch unbound installiert. Installiert habe ich über sudo apt install unbound. Aufgefallen ist es mit zwar auch schon aber ich konnte nichts damit anfangen.

Ich schau gleich mal ob ich es deaktivieren kann und teste nochmal deine unbound.conf ohne void.zone

[Nastra]

Mhhhh, ich denke das Skript wird nicht nur von unbound genutzt oder was meinst du? Wüsste gerade auch nicht wie ich es deaktivieren soll außer das ich es hard lösche oder umbenenne?

Code: Alles auswählen

 #!/bin/sh
# This script is called by "systemctl enable/disable" when the given unit is a
# SysV init.d script. It needs to call the distribution's mechanism for
# enabling/disabling those, such as chkconfig, update-rc.d, or similar. This
# can optionally take a --root argument for enabling a SysV init script
# in a chroot or similar.
set -eu

usage() {
    echo "Usage: $0 [--root=path] enable|disable|is-enabled <sysv script name>" >&2
    exit 1
}

ROOT=

# parse options
eval set -- "$(getopt -o r: --long root: -- "$@")"
while true; do
    case "$1" in
        -r|--root)
            ROOT="$2"
            shift 2 ;;
        --) shift ; break ;;
        *) usage ;;
    esac
done

NAME="${2:-}"

run() {
    if [ -n "$ROOT" ] && [ "$ROOT" != "/" ]; then
        _SKIP_SYSTEMD_NATIVE=1 chroot "$ROOT" /usr/sbin/update-rc.d "$@"
    else
        _SKIP_SYSTEMD_NATIVE=1 /usr/sbin/update-rc.d "$@"
    fi
}

[ -n "$NAME" ] || usage

case "$1" in
    enable)
        # call the command to enable SysV init script $NAME here..
        run "$NAME" defaults
        run "$NAME" enable
        ;;
    disable)
        run "$NAME" defaults
        run "$NAME" disable
        ;;
    is-enabled)
        # exit with 0 if $NAME is enabled, non-zero if it is disabled
        ls "$ROOT"/etc/rc[S5].d/S??"$NAME" >/dev/null 2>&1
        ;;
    *)
        usage ;;
esac

[chrbr]

Mhhhh, ich denke das Skript wird nicht nur von unbound genutzt oder was meinst du? Wüsste gerade auch nicht wie ich es deaktivieren soll außer das ich es hard lösche oder umbenenne?

Es sieht so aus, als würde es ein Wrapper für alle Dienste sein, die von systemd über den SysV Mechanismus gestartet werden sollen. Zum Deaktivieren kannst Du oberhalb oder unterhalb von set -eu ein exit 0 einfügen. Dann wird das Skript zwar aufgerufen, tut aber nichts.

[Nastra]

Werde ich gleich probieren . Habe deine unbound.conf gerade nochmal getestet und das neustart verhalten bleibt gleich dafür sind neue Warnungen aufgetreten. Bei der installation von unbound habe ich mich an diese offiziele Anleitung gehalten vom pi-hole Team:
https://docs.pi-hole.net/guides/dns/unbound/

Es wundert mich das die unbound.conf dort garnicht erwähnt wird.

Code: Alles auswählen

 Mai 17 19:50:01 Gr-SHS-4 unbound[27337]: [27337:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mai 17 19:50:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 17 19:50:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 17 19:50:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 17 19:50:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: May 17 19:50:02 unbound[27581:0] warning: use-systemd and do-daemonize should not be enabled at the same time
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: May 17 19:50:02 unbound[27581:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: May 17 19:50:02 unbound[27581:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: [27581:0] notice: init module 0: subnet
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: [27581:0] notice: init module 1: validator
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: [27581:0] notice: init module 2: iterator
Mai 17 19:50:02 Gr-SHS-4 unbound[27581]: [27581:0] info: start of service (unbound 1.13.1).
Mai 17 19:50:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 17 19:51:01 Gr-SHS-4 unbound[27581]: [27581:0] info: service stopped (unbound 1.13.1).
Mai 17 19:51:01 Gr-SHS-4 unbound[27581]: [27581:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mai 17 19:51:01 Gr-SHS-4 unbound[27581]: [27581:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mai 17 19:51:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 17 19:51:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 17 19:51:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 17 19:51:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: May 17 19:51:01 unbound[28068:0] warning: use-systemd and do-daemonize should not be enabled at the same time
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: May 17 19:51:01 unbound[28068:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: May 17 19:51:01 unbound[28068:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: [28068:0] notice: init module 0: subnet
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: [28068:0] notice: init module 1: validator
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: [28068:0] notice: init module 2: iterator
Mai 17 19:51:01 Gr-SHS-4 unbound[28068]: [28068:0] info: start of service (unbound 1.13.1).
Mai 17 19:51:01 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 17 19:52:02 Gr-SHS-4 unbound[28068]: [28068:0] info: service stopped (unbound 1.13.1).
Mai 17 19:52:02 Gr-SHS-4 unbound[28068]: [28068:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Mai 17 19:52:02 Gr-SHS-4 unbound[28068]: [28068:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Mai 17 19:52:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 17 19:52:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 17 19:52:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 17 19:52:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: May 17 19:52:02 unbound[28697:0] warning: use-systemd and do-daemonize should not be enabled at the same time
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: May 17 19:52:02 unbound[28697:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: May 17 19:52:02 unbound[28697:0] warning: Systemd mandatory ENV variable is not defined: LISTEN_PID
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: [28697:0] notice: init module 0: subnet
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: [28697:0] notice: init module 1: validator
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: [28697:0] notice: init module 2: iterator
Mai 17 19:52:02 Gr-SHS-4 unbound[28697]: [28697:0] info: start of service (unbound 1.13.1).
Mai 17 19:52:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server

Edit: Gerade das Skript angepasst mit einem exit 0 oberhalb von set -eu und einen Reboot gemacht. Leider auch keine Änderung

[chrbr]

Die Warnungen habe ich bei mir auch. Das ist mir bisher noch nicht aufgefallen. Ich habe aber inzwischen etwas anderes gefunden.
https://pi-hole.net/blog/2023/01/15/pi- ... -released/
Dort steht

Code: Alles auswählen

Native systemd service

We have added a native systemd service to avoid 
the systemd-sysv wrapper units and enhance 
service status tracking. (See #4924)

Vielleicht ist das interessant.
Nochmal zu systemctl status unbound.service. Dort stand ja in deinem Screenshot "disabled". Ist das immer so? Andererseits ist er "active". Ich vermute, das ist so, weil unbound von sysv über den Wrapper gestartet wird. Wenn der Wrapper sonst nicht benötigt wird wäre es vielleicht am besten, ihn zu deaktivieren.

[Nastra]

Scheint so als ob pi-hole früher auch dieses komische Skript genutzt hat zum starten. Bei unbound aus meinem repo scheinbar auch noch. Vielleicht sind wir ja auf der richtige spur. Das exit 0 hat ja scheinbar nicht geklappt.

Wie deaktiviert man so einen Wrapper genau?

Der service selber ist aktiv ob er enable oder disable ist macht keinen unterschied der Autostart läuft jede Minute :

Code: Alles auswählen

 XXX@Gr-SHS-4:~ $ sudo systemctl status unbound.service
● unbound.service - Unbound DNS server
     Loaded: loaded (/lib/systemd/system/unbound.service; disabled; vendor preset: enabled)
     Active: active (running) since Wed 2023-05-17 20:18:02 CEST; 2s ago
       Docs: man:unbound(8)
    Process: 13975 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
    Process: 13978 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
   Main PID: 13981 (unbound)
      Tasks: 1 (limit: 3932)
        CPU: 156ms
     CGroup: /system.slice/unbound.service
             └─13981 /usr/sbin/unbound -d -p

Mai 17 20:18:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 17 20:18:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.

[chrbr]

Zu den Warnungen: hier habe ich unbound.conf an zwei Stellen geändert.

Code: Alles auswählen

    # Detach from the terminal, run in background, "yes" or "no".
    # Set the value to "no" when unbound runs as systemd service.
    do-daemonize: no

Das ist per default "yes". Damit ist die "daemonize" Warnung weg.

Code: Alles auswählen

    # Use systemd socket activation for UDP, TCP, and control sockets.
    use-systemd: no

Hier geht es wie von mit durch zu schnelles Lesen nicht um systemd generell, sondern darum, wie die Informationen zu "control sockets" verfügbar gemacht werden. https://github.com/NLnetLabs/unbound/issues/410 fasst das gut zusammen. "no" ist auch der default Wert. Das kann man also auch auskommentieren.

Die drei Warnungen sind nach einem Neustart von unbound nun weg. Danke für den Hinweis!

[Nastra]

Cool dann hat es sich deine Mühe hier ja wenigstens etwas gelohnt.
Vielen Dank für die Unterstützung!

Edit: Gerade eine Antwort im pi-hole Forum vom Entwickler bekommen:

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.

Man oh man da habe ich wieder eine Dose der Pandora geöffnet, bin voll der BUG Magnet

[chrbr]

Man oh man da habe ich wieder eine Dose der Pandora geöffnet, bin voll der BUG Magnet

Das sind die wichtigsten Leute - oder wie sollen die Entwickler die Bugs finden?

Falls Du (noch) experimentierfreudig bist wäre es interessant, was nach folgenden Kommandos passiert oder nicht passiert.

Code: Alles auswählen

systemctl stop systemd-sysv
systemctl disable systemd-sysv

Damit sollte dann hoffentlich alles über systemd laufen.

Ansonsten könnte man in unbound.service den Wert von Restart=on-failure auf Restart=no setzen, und zwar nur um zu sehen, ob dort der Neustart beeinflussbar ist. Das wäre jedenfalls einfach zu testen.

[Nastra]

Du hast ja Recht, anders findet man die Bugs nicht. Bin ja froh das geholfen wird!

Habe gerade probiert systemd-sysv zu stoppen bzw. zu deaktivieren:

Code: Alles auswählen

 Failed to stop systemd-sysv.service: Unit systemd-sysv.service not loaded.
XXX@Gr-SHS-4:~ $ sudo systemctl disable systemd-sysv
Failed to disable unit: Unit file systemd-sysv.service does not exist.
XXX@Gr-SHS-4:~ $ sudo systemctl stop systemd-sysv
Failed to stop systemd-sysv.service: Unit systemd-sysv.service not loaded.

Die scheint es nicht zu geben

Die Restart=on-failure Zeile hatte ich heute Mittag bereits komplett entfernt aus der Service Datei. Hat aber auch keinen Unterschied gemacht. Oder meinst du auf no setzen hat andere Auswirkungen?

[chrbr]

Ach, ich habe vergessen zu fragen, ob die Pi-Hole Entwickler das Verhalten Deines Systems nachvollziehen können. Hast Du dazu Informationen?

[Nastra]

Inwieweit nachvollziehen, verstehe die Frage gerade nicht richtig?

Edit: Nach dem dritten mal lesen hat es jetzt klack gemacht, ist schon spät und war sehr früh wach

Nein bisher können sie sich auch keinen Reim darauf machen und sind irritiert. Zumindest nicht im First LVL Support.
Ist ja auch seltsam das ein systemd service nicht gestoppt werden kann und jede Minute ohne Fehler neustartet.

Mal schauen was die Jungs aus dem Second LVL sagen die ja jetzt gepingt wurden.

[chrbr]

Habe gerade probiert systemd-sysv zu stoppen bzw. zu deaktivieren:

Gibt denn

Code: Alles auswählen

systemctl|grep -i sysv

etwas brauchbares? Inzwischen habe ich auch einen relevanten Blog gefunden. Da steht aber wohl nicht, wie man den Wrapper abstellt. https://www.turnkeylinux.org/blog/debug ... nit-compat

Die Restart=on-failure Zeile hatte ich heute Mittag bereits komplett entfernt aus der Service Datei. Hat aber auch keinen Unterschied gemacht. Oder meinst du auf no setzen hat andere Auswirkungen?

Das weiß ich nicht. Wenn "no" hilft, dann wäre "on-abnormal" der nächste Versuch. Siehe man systemd.service, etwa Zeile 480.

[chrbr]

Was mir noch (reichlich spät) einfällt:
Zeigt systemctl --failed etwas sinnvolles?
Gibt es interessantes bei journalctl -f zur Zeit um den unbound Neustart zu sehen?

[Nastra]

Guten Morgen,

wenn ich

Code: Alles auswählen

systemctl|grep -i sysv

eingebe erscheint einfach eine neue Zeile ohne Ausgabe.

Das weiß ich nicht. Wenn "no" hilft, dann wäre "on-abnormal" der nächste Versuch. Siehe man systemd.service, etwa Zeile 480.

Beides probiert mit einem anschließenden

Code: Alles auswählen

sudo systemctl daemon-reload 

der Service startet weiter fröhlich neu. Ich habe die Zeile auch komplett entfernt macht ebenfalls keinen unterschied.

Das journalctl zeigt keinerlei Fehler an was ziemlich blöd ist:

Code: Alles auswählen

Mai 18 06:46:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:46:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:47:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:47:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:47:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:47:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:47:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:48:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:48:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:48:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:48:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:48:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:49:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:49:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:49:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:49:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:49:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:50:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:50:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:50:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:50:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:50:01 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:51:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:51:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:51:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:51:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:51:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:52:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:52:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:52:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:52:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:52:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:53:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:53:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:53:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:53:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:53:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:54:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:54:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:54:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:54:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:54:01 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:55:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:55:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:55:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:55:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:55:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:56:02 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:56:02 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:56:02 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:56:02 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:56:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:57:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:57:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:57:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:57:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:57:02 Gr-SHS-4 systemd[1]: Started Unbound DNS server.
Mai 18 06:58:01 Gr-SHS-4 systemd[1]: Stopping Unbound DNS server...
Mai 18 06:58:01 Gr-SHS-4 systemd[1]: unbound.service: Succeeded.
Mai 18 06:58:01 Gr-SHS-4 systemd[1]: Stopped Unbound DNS server.
Mai 18 06:58:01 Gr-SHS-4 systemd[1]: Starting Unbound DNS server...
Mai 18 06:58:01 Gr-SHS-4 systemd[1]: Started Unbound DNS server.

Im Debug Modus zeigt er das hier, was meiner Ansicht aber auch unauffällig ist:

Code: Alles auswählen

XXX@Gr-SHS-4:~ $ sudo unbound -d -vvvv
[1684386267] unbound[107313:0] notice: Start of unbound 1.13.1.
[1684386267] unbound[107313:0] debug: increased limit(open files) from 1024 to 4140
[1684386267] unbound[107313:0] debug: creating udp4 socket 127.0.0.1 5335
[1684386267] unbound[107313:0] debug: creating tcp4 socket 127.0.0.1 5335
[1684386267] unbound[107313:0] debug: chdir to /etc/unbound
[1684386267] unbound[107313:0] debug: drop user privileges, run as unbound
[1684386267] unbound[107313:0] debug: switching log to /var/log/unbound/unbound.log

Echt zum verrückt werden

[MSfree]

ich bisher davon ausgegangen bin das es ein Problem von unbound bzw. pi-hole ist.

Beides sind DNS-Resolver und beide müssen auf Port 53 ansprechbar sein. Das kann nicht gut gehen.

Warum willst du 2 DNS-Resolver auf derselben Hardware laufen lassen? Für mich ist schon allein das ziemlich fragwürdig.

Davon abgesehen, logt längst nicht alles ins Journal und bei vielen Programmen muß an das Loglevel hochsetzen, um überhaupt Meldungen zu bekommen. Da ein hohes Loglevel die Festplatte vollschreiben könnte, ist das im Normalzustand nicht eingeschaltet.

[Nastra]

Beides sind DNS-Resolver und beide müssen auf Port 53 ansprechbar sein. Das kann nicht gut gehen. Warum willst du 2 DNS-Resolver auf derselben Hardware laufen lassen? Für mich ist schon allein das ziemlich fragwürdig.

Mhhh, das höre ich jetzt zum ersten mal. Sämtliche Tutorials im Netzt sowie das pi-hole Team beschreiben wie beide Programme auf einem Gerät betrieben werden. pi-hole hört auf Port 53 und unbound in dieser Konfiguration auf 5335.

Hier zum Beispiel Teil 1 und 3:
https://www.creativeturtle.de/tutorials/pihole-teil-1/

Davon abgesehen, logt längst nicht alles ins Journal und bei vielen Programmen muß an das Loglevel hochsetzen, um überhaupt Meldungen zu bekommen. Da ein hohes Loglevel die Festplatte vollschreiben könnte, ist das im Normalzustand nicht eingeschaltet.

Dem Hinweis werde ich prüfen bzw. schauen ob unbound die Möglichkeit anbietet das loglvl zu erhöhen.

[chrbr]

Auf dem Pi-Hole sollte wirklich nur ein DNS Server laufen. Nach meinem Verständnis sieht das so aus:

Code: Alles auswählen

Internet---Router---------Pi-Hole sendet DNS Abfragen ins Internet über Port 53  
                     |            beantwortet DNS Abfragen via Unbound und Port 5335
                     |
                      ----PCs machen DNS Abfragen über das Pi-Hole Port 5335

Ist das nicht so?

[Nastra]

Problem gefunden!

@MSfree Dadurch das ich dir das Tutorial verlinkt habe kam ich auch nochmal dazu es zu lesen. Ich habe mein unbount zwar nach der Anleitung vom Phiole Team aufgesetzt https://docs.pi-hole.net/guides/dns/unbound/ aber die Update Lösung gem. Teil 3 des Tutorial (Automatische Updates) von https://www.creativeturtle.de/tutorials/pihole-teil-1/ verwendet. Und dort ist der Fehler verborgen.

In dem Tutorial wurde tatsächlich ein Cronjob für root sowie ein Update Skript für unbound angelegt. In diesem Skript ist ein restart Befehl sowie ein scheinbar falscher Eintrag für Cron der dieses Verhalten vom Service ausgelöst hat. Nach dem ich es entfernt habe läuft der unbound.service nun wie gewünscht durchgängig .

Bei der Fehleranalyse bzw. Prüfung nach cronjobs habe ich fälschlicherweise nur nach Jobs vom User geprüft und nicht für root und deswegen ist es nicht aufgefallen.

Automatisches Update werde ich jetzt über systemd.timer einrichten da schaue ich öfter rein als in die cron Geschichte

Anbei die beiden Dateien die den Fehler ausgelöst haben aus dem Tutorial:

Skript Automatische Updates

Code: Alles auswählen

#!/bin/bash
     wget -O root.hints https://www.internic.net/domain/named.root &&
     (
      mv -fv root.hints /var/lib/unbound/
      service unbound restart
     )

Crontab:

Code: Alles auswählen

* * * */4 * root /home/pi/update_unbound_root_dns.sh >/dev/null 2>&1

@chrbr @Msfree vielen Dank für die Unterstützung!