MichaIng
commented
3 years ago If I remember it correctly, FTL does not have any issues when logs are ~atomically cleared. We had some special handling for the RAM log clearing script in place some years ago, but it turned out (discussed here somewhere) that this was not required anymore, so we removed it. Logs are cleared via simple empty redirect > pihole-FTL.log, which should be near to atomic on a tmpfs.
I saw one dietpi script cleaning the log at the same time pi-hole was rotating the log.
We can try verify this:
cp -a /var/log/pihole-FTL_full.log var/log/pihole-FTL.log
cp -a /var/log/pihole_full.log var/log/pihole.log
pihole flush once quiet &
> /var/log/pihole-FTL.log &
> /var/log/pihole.logDoing this in a loop, probably with a minimal delay after the pihole call for initiating the shell and the steps until the actual log file clearing is performed? Probably better to do the final logrotate call to skip the Pi-hole scripts wrapping it:
logrotate --force /etc/pihole/logrotateAnother approach: As Pi-hole's cron job clears logs exactly at midnight, on DietPi one can use dietpi-cron to change the hourly cron job time to something like :15, so that collisions are ruled out. The default is btw :17, so it would need to be manually changed have a chance that those are done concurrently.
But actually, I do not see a chance that this causes an FTL issue:
- Pi-hole log clearing is done via cron, completely independent from the FTL process.
- The
pihole>piholeLogFlush.shscripts, called by the cron job, have noset -e, hence do not fail on command error, and the logrotate call is not specially error-handled, so even the cron job itself would not fail.
I'm not sure how logrotate behaves on write collisions, but the worst that can happen is malformed log file. While pihole -t might then fail to parse affected lines in /var/log/pihole.log, I'm not sure whether FTL would mind in any way, as it just goes on writing its logs but not reading them anyway?
EDIT: Ah, actually logrotate should not be installed as long as RAMlog is. It is not by default on DietPi at least, as it does not make sense to run two log clearing systems, and rotating logs in a RAMlog 😉. In this case the Pi-hole log clearing is done via:
cp -p /var/log/pihole.log /var/log/pihole.log.1
echo " " > /var/log/pihole.log
chmod 644 /var/log/pihole.logSo logrotate can be further ruled out, and I'm pretty sure that those shell commands handle concurrency gracefully, at least I never saw any issue that would indicate otherwise.
Since the pihole flush call does not create any kind of lock that could be respected/checked by FTL, I also do not think that FTL has any issues when trying to log something while either logrotate or > /var/log/pihole-FTL.log writes to them.
Looking at pihole updatechecker local (running every 10 minutes, actually what for?) is does nearly nothing aside of a few git calls to check the local branch and version. Also the remote version check (running once a day) does three curl calls, nothing else. I do not believe that those two cron jobs have any chance to crash anything, and again, it's a completely independent process, not related to the FTL service. Also those do not write to the Pi-hole log files, only to system log/journal via cron service.
I'd have another look into journalctl, which combines all system and service logs, to check entries around the time when DNS stopped working.
stphn17
yubiuser
DL6ER
pablopoo
Versions
Platform
Expected behavior
Pihole is constantly running on my Synology and was very reliable up until the last version - meaning: no reboots, no maintenance, no nothing.
Actual behavior / bug
Sometimes during the night Pihole stops resolving DNS at all. Webpages no longer load and devices can no longer connect.
If you take a look at the query log during that time you can see that no queries were processed after 03:49:45.
After you restart the resolver or reboot pihole completely everything works again for about a week.
Steps to reproduce
Steps to reproduce the behavior:
Debug Token
Screenshots
Additional context