When I boot my PI afterwards I do have dead.letter file for root with following content:
fatal: unable to access 'https://github.com/pi-hole/pi-hole/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/web/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/FTL/': Could not resolve host: github.com
github and all other DNS resolution works fine afterwards, seems network is not available during check time of updates?
When your reboot your Pi, it takes a bit of time for all the apps and services to start (including Pi-hole). Try this experiment:
pihole -statusdig github.com @127.0.0.1pi@pihole:[~] $ pihole status
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
pi@pihole:[~] $ dig github.com @127.0.0.1
; <<>> DiG 9.18.24-1-Raspbian <<>> github.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16652
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;github.com. IN A
;; ANSWER SECTION:
github.com. 1583 IN A 140.82.121.3
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jul 13 19:30:12 CEST 2024
;; MSG SIZE rcvd: 55
pi@pihole:[~] $ pihole status
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
pi@pihole:[~] $ dig github.com @127.0.0.1
; <<>> DiG 9.18.24-1-Raspbian <<>> github.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 647
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;github.com. IN A
;; ANSWER SECTION:
github.com. 1746 IN A 140.82.121.3
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jul 13 19:27:29 CEST 2024
;; MSG SIZE rcvd: 55
These are the expected results. Pi-hole is running and correctly resolving the requested domain.
seems NW is not available at the time pihole checks for updates
Should there be a sleep in the FTL service file?
Hmm, dead.letter is a file created by some email clients under certain circumstances, e.g. if you abort editing an email via Ctrl + C.
I'm unsure how Pi-hole would be involved here.
Did you perhaps configure to be alerted of system failures via email?
And did you check when that file was actually created?
If that's weeks ago, we may be hunting a red herring.
yes, it is created during boot/startup process, I did serveral reboots
Did you perhaps configure to be alerted of system failures via email?
no, alterting doing not via email, I am using go-sendxmpp mainly
I suspect your alerting system loads prior to Pi-hole.
I also checked the FTL.service, there is a pre-hook but nothing related to sleep or similar, also the network target is a requirement, so I out of ideas ....
not my alterting system, its the std. pihole check for new/updated versions:
fatal: unable to access 'https://github.com/pi-hole/pi-hole/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/web/': Could not resolve host: github.com
fatal: unable to access 'https://github.com/pi-hole/FTL/': Could not resolve host: github.com
You said this happens on boot.
Apparently the issue is: a cronjob (or something else) is trying to update Pi-hole before the network is available.
Also, the dead.letter file seems to be the result of a failed attempt to send an email (generated by your alerting system, because Pi-hole doesn't generate emails).
This is an OS level issue. The network is not ready when these services are trying to use it.
I do have no crontab job setup manually to check github for pihole updates , is there such a check done by pihole? of so where is the github call script located?
Pi-hole has a cronjob to check for updates (see here), but your issue is your network is not available when this cronjob runs.
Running as root cronjob? Havent found for User pi, or running as pihole? No clue?
How can I assure that nw is available while update checking during reboot?
Why are you adding a check for update on each boot? Pi-hole checks for updates while running.
@jfb I havent added anything manually, it is left unchanged, so how can it be adjusted to not check after reboot? The reboot check is done in std cron for pihole setup in /etc/cron.d/pihole:
pi@pihole:[/etc/cron.d] $ cat pihole | grep reboot
@reboot root /usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate
@reboot root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker reboot
Without knowing what process is creating that dead.letter file, it will be difficult to further analyse your issue.
It is unclear what state the network was actually in when whatever process wrote information to that dead.letter email.
The lines that show in that email just show failures to access remote hashes from https://github.com/pi-hole/<component-repo>/.
But Pi-hole's update check would do so only after already having tried to access remote versions from https://api.github.com/repos/pi-hole/<component-repo>//... - and we do not see any complaints about those in your dead.letter:
In any case, you won't lose any important functionality when those resources are not accessible during an updatecheck after reboot.
Pi-hole regularly checks its core, web and FTL repositories for updates daily as well as upon reboot (in the latter case, it would wait for 30 seconds after being triggered before accessing the remote repositories, to allow the network stack to come up).
Granted, it's still irritating that you don't know what process is writing to dead.letter, and why.
@Bucking_Horn thanks for the deep and profound answer! I did some testing and the solution to avoid the dead.letter is:
/etc/cron.d/pihole:
comment out the updatechecker @reboot time
# @reboot root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker reboot
So, it is proven that the creation of the dead.letter is caused by the cron.d pihole script.
I did several tests, but I didn't manage to handle it with the "sleep 30" command.
Not sure, how a "sleep 30" command does appropriate fit into the shell script line, I didn't manage that, so I have chosen the "hard way".
Any recommendations in how-to implement the sleep there would be more than welcome, also maybe I am not the only one with the dead.letter problem and the pihole cron.d script could be changed from the pihole development side as a fix.
Some process yet unknown is monitoring your logs and under certain unknown conditions then may try to create an email with excerpts of those logs.
Commenting out Pi-hole's reboot cron job just removes the trigger for whatever process is creating that dead.letter file.
Pi-hole does not create it (and you are the first user to report that file to contain Pi-hole related messages).
Not sure what you are trying to do?
As explained, the update check already sleeps for 30 seconds on reboot.
And your earlier dig results show no issues with github.com when your system is up.