Pihole verliert Sonntags Domains on Blacklist

Wie sehen die Zeilen in der Datei /etc/pihole/pihole-FTL.log nach dem pihole restartdns aus?

Das Problem besteht auch weiterhin.

Die Datei pihole-FTL.log liegt bei mir in /var/log/ und sieht aktuell wie folgt aus:
[2019-04-23 16:00:01.039 10379] Resizing "/FTL-strings" from 16384 to 20480
Auffälliger scheint mir pihole.log , der Zeitraum passt nämlich genau .

Apr 21 03:52:50 dnsmasq[10379]: read /etc/hosts - 6 addresses
Apr 21 03:52:50 dnsmasq[10379]: read /etc/pihole/local.list - 4 addresses
Apr 21 03:52:50 dnsmasq[10379]: read /etc/pihole/black.list - 3 addresses
Apr 21 03:52:50 dnsmasq[10379]: failed to load names from /etc/pihole/gravity.list: Permission denied
Apr 21 07:58:56 dnsmasq[10379]: reducing DNS packet size for nameserver ::1 to 1280
Apr 21 17:15:51 dnsmasq[10379]: reducing DNS packet size for nameserver 127.0.0.1 to 1280
Apr 21 21:58:11 dnsmasq[10379]: read /etc/hosts - 6 addresses
Apr 21 21:58:11 dnsmasq[10379]: read /etc/pihole/local.list - 4 addresses
Apr 21 21:58:11 dnsmasq[10379]: read /etc/pihole/black.list - 3 addresses
Apr 21 21:58:17 dnsmasq[10379]: read /etc/pihole/gravity.list - 780578 addresses

Aktuell sieht es auch nicht besser aus…

Apr 23 19:09:01 dnsmasq[10379]: failed to send packet: Operation not permitted
Apr 23 19:09:11 dnsmasq[10379]: failed to send packet: Operation not permitted
Apr 23 19:09:11 dnsmasq[10379]: failed to send packet: Operation not permitted
Apr 23 19:09:11 dnsmasq[10379]: failed to send packet: Operation not permitted
Apr 23 19:09:11 dnsmasq[10379]: failed to send packet: Operation not permitted
Apr 23 19:49:11 dnsmasq[10379]: reducing DNS packet size for nameserver ::1 to 1280

Es ist wieder Sonntag und ich habe folgendes feststellen können:

cat pihole-FTL.log

[2019-04-28 03:52:23.477 10379] Compiled 2 Regex filters and 17 whitelisted domains in 0.5 msec (0 errors)
[2019-04-28 03:52:25.358 10379] /etc/pihole/black.list: parsed 3 domains (took 0.2 ms)

cat pihole.log

Apr 28 03:52:25 dnsmasq[10379]: read /etc/hosts - 6 addresses
Apr 28 03:52:25 dnsmasq[10379]: read /etc/pihole/local.list - 4 addresses
Apr 28 03:52:25 dnsmasq[10379]: read /etc/pihole/black.list - 3 addresses
Apr 28 03:52:25 dnsmasq[10379]: failed to load names from /etc/pihole/gravity.list: Permission denied
Apr 28 08:41:40 dnsmasq[10379]: reducing DNS packet size for nameserver ::1 to 1280
-rw-r--r-- 1 root   root          112 Apr 28 03:52 local.list
-rw-r--r-- 1 root   root           56 Apr 28 03:52 black.list
-rw-r----- 1 root   root     17315055 Apr 28 03:52 gravity.list

es scheint so, also würden die world-Leserechte für die Datei gravity.list verloren gehen,
nach einem pihole -g sind die Rechte wieder vorhanden.
-rw-r--r-- 1 root root 17315079 Apr 28 12:14 gravity.list

Gibt es keine Möglichkeit diese automatische Aktualisierung einmal die Woche zu unterbinden? :thinking:

Ja im cron. Aber mit die nachste update vom pi-hole selbst muss du das auf neuem machen.

Wo finde ich den Eintrag genau?

It is like scheduler in Windows. You can run commands/scripts at defined time.

The full name is Cron table, command crontab and I used the shortname cron expecting it was known.

https://en.m.wikipedia.org/wiki/Cron

I have to look into how to disable the pihole.cron file. The source of that file is in /etc/.pihole

I am doing this from memory so it could be different.

Update.
The cron file is located here:
/etc/cron.d/pihole

Deleting that file stops all pihole jobs. It will be recreated on repair or pihole -up

Thank you, but then my problem is, how could this problem be fixed and why only I have this problem…

I have sometimes pihole not being able to change files, out of the blue after weeks of working fine. No updates made to pihole.

I don’t know what changed the file access and after setting it right again it works till the next hickup.

Yours should be better traceable but you have to look at official support for that.

Tut mir leit, ich bemerke gerade das ich auf English geschieben habe.

Ich habe mir dieses Jahr den Luxus eines zweiwöchigen Osterurlaubs ohne Laptop gegönnt, daher erst jetzt meine Antwort.

Sehr gut! Ja, das wird es sein.

Ich vermute, dass Du eine benutzerdefinierte umask verwendest?

Was ist die Ausgabe von

umask

?

Auf meinem NanoPi NEO ist es 0022. Die erste Null kann hier ignoriert werden. Somit bleibt 022.

Der Standard für neue Dateien ist unter Linux immer 666 (rw-rw-rw-).

Maskiert mit meiner umask ist 666 - 022 = 644 (rw-r--r--) bei mir das Standardset an Berechtigungen für neue Dateien.