Thank you very much for reading my post and lending a hand.
I did look up that error message. As far as I could tell, there was no consensus cause for that error, and a few actions that helped some people (none related to Pi-hole).
Some of the steps I took after looking up that error were:
removing and reinstalling the curl package
increasing the memory of the container
checking permissions (which I included in my post for /etc/pihole. (I am not sure if the gravity blocklist is stored elsewhere, and can check the permissions for that file.)
I am not too sure how curl works - some discussions of it suggested to me if buffers before writing, and perhaps that is an issue, but I could not find any issues with swap or memory. I came to a point where I couldn't solve the problem myself.
Any insights would be much appreciated.
Was there anything in the tricorder that caught your eye that I should investigate?
When I enter that command, and add a -v verbose flag, I get this output:
Resolving timed out after 10000 milliseconds
Closing connection 0
(Since it says resolving timed out, I would note that when I seek to update Gravity, it begins by indicating that 'DNS resolution is currently unavailable' and then a few seconds later indicates DNS is available and continues the process (ultimately not succeeding because of a "Connection Refused". For example:
[✗] DNS resolution is currently unavailable
[✓] DNS resolution is available
[i] Neutrino emissions detected...)
(CallMeCurious, thank you for the link regarding curl. The reason I referenced that command in my post is because the output was requested in an older post on the forums regarding the "connection refused" issue when seeking to update gravity. Sorry I did not explain that!)
Thank you very much.
Edit:
I made an error putting in this command before my initial post:
I apologise for that, and I hope this additional information is not a distraction, I just wanted to update you. The issue with Gravity not updating because of a "Connection Refused" still exists (just checked).
Thank you very much. After reading your post, I entered the command with -S (uppercase) and the output was
curl: (28) Resolving timed out after 10000 milliseconds
I had a look for information about the cause of curl: (28), and one of the potential causes is a poorly-configured dns server. The pihole diagnostics indicate pihole is working as a dns server for clients, but it isn't clear it tests for its own DNS. I tested that and it was not working for its own lookups.
The resolv.conf for the underlying Debian install on which pihole resides points to my router as the nameserver, which in turn provides the static ip address for the pihole machine as the DNS server. I thought this was the correct approach but that seems to have been an error on my part. I left the router as is, but changed the nameserver for the underlying Debian OS to a Quad9 option, and then to 127.0.0.1, and in each case, gravity updated fine.
I have left the nameserver for the pihole machine as 127.0.0.1 consistent with this older discussion.
So I think all is working ok now, but would appreciate any thoughts on if I am missing something. I do not fully understand why the original setting (namesever on Debian pointing to the router, as with other clients on the network) doesn't work. (I've read this, but it is not gelling.)
I ran another pihole debug (Token: https://tricorder.pi-hole.net/IdRD9Hlj/ ) and didn't see any issues timestamped after the change, but am obviously ignorant.
The good news, though, is things appear to be working.
Again, many thanks for the assistance so far (!) and any insight on why the other settings were not working would be much appreciated.
If you are not using the machine where Pi-hole is installed to browse the internet, then you can set its DNS to a public DNS server (like Quad9, Google, or any other).
This will avoid DNS issues on the server when Pi-hole is offline.