-
Now you have a confirmed second case, thanks for that @beerns
-
A user on another dutch forum makes the following remark, translation:
For some reason my pihole triggers the service pihole-FTL restart section of the script, however, there are 3 choices there:
- svc="
kill-SIGRTMIN $(pidof ${resolver})" - svc="
killall-s SIGHUP ${resolver}" - svc="
service${resolver} restart"
Unfortunately, I haven't been able to figure out why my pihole makes the service choice, while your pihole obviously makes another choice.
Given the fact that cron executes the script with the path /usr/bin:/bin:/usr/local/bin/ (see earlier), the script will only fail in one of three cases:
- kill -> which kill -> /bin/kill -> success (on the path used by cron)
- killall -> which killall -> /usr/bin/killall -> success (on the path used by cron)
- service -> which service -> /usr/sbin/service -> fail (NOT on the path used by cron)
All I do, before cron executes the weekly gravity update (I do this on Saturday 23h00, success or failure is registered) is download some lists locally and process them, to make them pihole compatible, examples shallalist, using md5 checksum to ensure integrity and duckduckgo trackers.
Looking into this for more than a day now, I'm convinced this is a real problem, that some users may or may not notice.
For now, I solved the problem, by creating a symbolic link for service:
sudo ln -s /usr/sbin/service /usr/local/bin/service
Another possible (better?) solution would be to change the code:
…
else
# A full restart has been requested
serviceCommand=$(which service)
svc="${serviceCommand} ${resolver} restart"
str="Restarting DNS server"
fi
…
It would probably be wise to do the same for the kill and killall binaries, this to avoid future problems.