Pihole verliert Sonntags Domains on Blacklist

Hallo zusammen,

seit einigen Wochen ist mir negativ aufgefallen, dass meine Blocklist plötzlich nur noch die drei Domains (die von meiner manuellen Blacklist) enthält. Ein pihole -g löst das Problem. Allerdings einige Tage später, das gleiche Problem. Auch ein Update auf Version 4.2.1 half nicht. Nach einigen Tagen ist die Blocklist wieder geleert (bis auf die drei Domains).

Leider konnte ich dazu bislang nichts finden.
Wo kann ich anfangen nach dem Fehler zu suchen?
Privacy steht auf: Hide Domains

Raspberry Pi 3 mit Devuan Ascii

Hallo,

die Listen, welche man im Webinterface unter Settings -> Blocklists findet, werden in der Datei /etc/pihole/adlists.list gespeichert.

Hast du evtl. für irgendein Szenario einen Job oder Script angelegt, bei dem mit dieser Datei gearbeitet wird?

Vielen Dank für deine Antwort.
Einen Job habe ich nicht eingerichtet.
Die Blockiertlisten habe ich per Terminal händisch eingefügt, sie werden aber selbst zu dem Zeitpunkt wenn im Webinterface nur eine 3 steht, unter Einstellungen -> Blocklists als Enabled aufgeführt.
Ein Debuglog zu diesem Zeitpunkt zeigte mir auch nichts brauchbares an.

Kann es sein, dass wenn die Blocklisten automatisch aktualisiert werden, keine Internetverbindung besteht?

Wann die Listen aktualisiert werden, siehst du mit

grep "updateGravity" /etc/cron.d/pihole

Wissentlich habe ich dafür keinen Cronjob angelegt.
Die Ausgabe:
36 3 * * 7 root PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log

You should already have an existing cron set up by Pi-Hole for this purpose, similar to this one from a user:

-rw-r--r-- 1 root root 1704 Feb 17 16:07 /etc/cron.d/pihole
   40 4   * * 7   root    PATH="$PATH:/usr/local/bin/" pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log

Musst du auch nicht. Dieser Job wurde ohne dein Zutun angelegt.
Kernfrage war eher, ob die Listen deswegen nicht aktualisiert werden können, weil zu dem Zeitpunkt (Sonntag 3:36 laut deiner Ausgabe) kein Internetzugang möglich ist.

Was mich irritiert, du sagst unter Settings->Blocklists sind zwar Listen eingetragen und aktiviert, sie werden aber nicht berücksichtigt.

Also laut Ereignismonitor meiner Fritz!Box war die ganze Zeit eine Internetverbindung vorhanden.

Genau, das irritiert mich nämlich auch.

Fehler oder Auffälligkeiten in der Datei /var/log/pihole_updateGravity.log?

Ich würde sagen nein.
Zumal ein manuelles pihole -g das Problem dann auch löst.

Wenn das Problem wieder auftritt, achte mal darauf, ob es zufällig an einem Sonntag der Fall ist (Stichwort automatisches Update der Listen über o.g. cronjob). Zudem, dann auch nochmals in die /var/log/pihole_updateGravity.log schauen.

Das würde schon hinkommen, da gestern Abend noch alles geblockt wurde und mir heute Mittag aufgefallen war, dass die Liste wieder fast leer war.
Ich behalte es mal im Auge und melde mich hier wieder mit Neuigkeiten.

Das Problem ist wieder aufgetreten... :face_with_raised_eyebrow:
Die Datei /var/log/pihole_updateGravity.log wurde zuletzt geändert: Feb 24 03:57
In der Datei ist nichts auffällig, Retrieval successful oder No changes detected, auch heute war laut meiner Fritz!Box das Internet aktiv.
Zwischenzeitlich habe ich auf die aktuellste Version 4.2.2 aktualisiert.

Ist es denn möglich, dass ich einfach das automatische Aktualisieren der Liste abschalte und somit den Fehler umgehe?

Die Frage die sich mir stellt, wieso wurde die Datei das letzte mal um 3:57 Uhr verändert, obwohl der Cronjob auf 3:36 Uhr steht.

Hatte ich auch schon. Bei mir hat einfach der Verbindungsaufbau zur Seite oder der Download der Liste auffallend lang gedauert. Wenn man dann noch mehrere Listen von der selben Quelle bezieht...

Was passiert eigentlich, nachdem du das Kommando aus deinem cronjob von oben manuell ausführst?

pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log

Also wenn ich das
pihole updateGravity >/var/log/pihole_updateGravity.log || cat /var/log/pihole_updateGravity.log
genau so ausführe, dann:
-bash: /var/log/pihole_updateGravity.log: Keine Berechtigung

pihole wird doch auch als normaler User ausgeführt. :thinking:

Das Problem ist hier, dass der normale Nutzer nicht in das Systemverzeichnis /var/log schreiben darf. Der Teil rechts vom > ist also problematisch.

Kannst Du einmal den Inhalt der Datei /var/log/pihole_updateGravity.log zeigen nachdem ein automatisches Update (z.B. heute!) nicht funktioniert hat?

Tatsächlich heute, Mär 3 03:52 aber wieder nicht die gleiche Uhrzeit. :thinking:

  [i] Pi-hole blocking is enabled
  [i] Neutrino emissions detected...
  [✓] Pulling blocklist source list into range

  [i] Target: adaway.org (hosts.txt)
  [✓] Status: No changes detected

  [i] Target: www.malwaredomainlist.com (hosts.txt)
  [✓] Status: No changes detected

  [i] Target: mirror1.malwaredomains.com (justdomains)
  [✓] Status: No changes detected

  [i] Target: zeustracker.abuse.ch (blocklist.php?download=domainblocklist)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: hosts-file.net (ad_servers.txt)
  [✓] Status: No changes detected

  [i] Target: raw.githubusercontent.com (hostnames.txt)
  [✓] Status: Retrieval successful

  [i] Target: s3.amazonaws.com (simple_tracking.txt)
  [✓] Status: No changes detected

  [i] Target: s3.amazonaws.com (simple_ad.txt)
  [✓] Status: No changes detected

  [i] Target: tspprs.com (spam)
  [✓] Status: No changes detected

  [i] Target: tspprs.com (tracking)
  [✓] Status: No changes detected

  [i] Target: raw.githubusercontent.com (adservers.txt)
  [✓] Status: Retrieval successful
  [✓] Format: Adblock

  [i] Target: raw.githubusercontent.com (spyware.txt)
  [✓] Status: Retrieval successful
  [✓] Format: Adblock

  [i] Target: media.kuketz.de (mobile_list.txt)
  [✓] Status: No changes detected

  [i] Target: github.com (spy.txt)
  [✓] Status: Retrieval successful

  [i] Target: hosts-file.net (grm.txt)
  [✓] Status: No changes detected

  [i] Target: reddestdream.github.io (minimalhosts)
  [✓] Status: No changes detected

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (w3kbl.txt)
  [✓] Status: No changes detected

  [i] Target: v.firebog.net (AdguardDNS.txt)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (adservers.txt)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (Easylist.txt)
  [✓] Status: Retrieval successful

  [i] Target: pgl.yoyo.org (serverlist.php?hostformat=hosts;showintro=0)
  [✓] Status: No changes detected

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: www.squidblacklist.org (dg-ads.acl)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (Easyprivacy.txt)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (Prigent-Ads.txt)
  [✓] Status: Retrieval successful

  [i] Target: gitlab.com (notrack-blocklist.txt)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (spy.txt)
  [✓] Status: Retrieval successful

  [i] Target: hosts-file.net (exp.txt)
  [✓] Status: No changes detected

  [i] Target: hosts-file.net (emd.txt)
  [✓] Status: Retrieval successful

  [i] Target: hosts-file.net (psh.txt)
  [✓] Status: Retrieval successful

  [i] Target: mirror.cedia.org.ec (immortal_domains.txt)
  [✓] Status: No changes detected

  [i] Target: www.malwaredomainlist.com (hosts.txt)
  [✓] Status: No changes detected

  [i] Target: bitbucket.org (Mandiant_APT1_Report_Appendix_D.txt)
  [✓] Status: No changes detected

  [i] Target: v.firebog.net (Prigent-Malware.txt)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (Prigent-Phishing.txt)
  [✓] Status: Retrieval successful

  [i] Target: gitlab.com (notrack-malware.txt)
  [✓] Status: Retrieval successful

  [i] Target: ransomwaretracker.abuse.ch (RW_DOMBL.txt)
  [✓] Status: Retrieval successful

  [i] Target: ransomwaretracker.abuse.ch (CW_C2_DOMBL.txt)
  [✓] Status: Retrieval successful

  [i] Target: ransomwaretracker.abuse.ch (LY_C2_DOMBL.txt)
  [✓] Status: Retrieval successful

  [i] Target: ransomwaretracker.abuse.ch (TC_C2_DOMBL.txt)
  [✓] Status: Retrieval successful

  [i] Target: ransomwaretracker.abuse.ch (TL_C2_DOMBL.txt)
  [✓] Status: Retrieval successful

  [i] Target: v.firebog.net (Shalla-mal.txt)
  [✓] Status: Retrieval successful

  [i] Target: raw.githubusercontent.com (hosts)
  [✓] Status: Retrieval successful

  [i] Target: www.squidblacklist.org (dg-malicious.acl)
  [✓] Status: Retrieval successful

  [i] Target: zerodot1.gitlab.io (hosts)
  [✓] Status: Retrieval successful

  [✓] Consolidating blocklists
  [✓] Extracting domains from blocklists
  [i] Number of domains being pulled in by gravity: 1003895
  [✓] Removing duplicate domains
  [i] Number of unique domains trapped in the Event Horizon: 744789
  [i] Number of whitelisted domains: 17
  [i] Number of blacklisted domains: 3
  [i] Number of regex filters: 2
  [✓] Parsing domains into hosts format
  [✓] Cleaning up stray matter

  [✓] DNS service is running
  [✓] Pi-hole blocking is Enabled

Ein nachträgliches pihole -g um die Blockliste wieder zu befüllen, schreibt aber nicht in diese Datei. Ich hatte schon überlegt als Workaround einen Cronjob um 5:00 Uhr für pihole -g einzustellen.

Komisch, komisch. Das zweigt eigentlich das alles einwandfrei funktioniert haben sollte...

Ich meine ... ja ... das kannst Du probieren, aber der Aufruf um 3 Uhr irgendwas ist nichts anderes (-g und updateGravity sind identisch), der einzige Unterschied ist, dass der Cronjob die Ausgaben in eben jene Datei umleitet statt sie auf einem (dann nicht existenten) Terminal zu zeigen. Das ändert jedoch nichts an der Funktion.

TODO für nächsten Sonntag, bitte bevor Du pihole -g manuell aufrufst:

  • Ist die Datei /etc/pihole/gravity.list morgens leer?
  • Hilft evtl. pihole restartdns anstelle von pihole -g weiter falls die Datei nicht leer ist?

Die Datei ist nicht leer, ein pihole restartdns löst das Problem allerdings auch nicht.
Sehr skurril, lediglich pihole -g schafft abhilfe.