I've updated to the latest docker image without issue. Perhaps your specific configuration has some interesting settings?
Brought up the docker container on a two different PCs (one running Debian and the other Ubuntu) with no pre-existing configuration at all and a very simple docker-compose.yml file and get the same error:
pihole | [✗] DNS service is NOT listening
pihole | kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
docker-compose.yml
version: "3"
# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
pihole:
restart: always
container_name: pihole
image: pihole/pihole:latest
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp"
- "80:80/tcp"
- "443:443/tcp"
environment:
TZ: 'Europe/London'
WEBPASSWORD: 'xxxxxxxxxx'
# Volumes store your data between container upgrades
volumes:
- './etc-pihole/:/etc/pihole/'
- './etc-dnsmasq.d/:/etc/dnsmasq.d/'
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped
Do the exact same thing using 5.7 and it starts up fine:
pihole | [✓] DNS service is listening
pihole | [✓] UDP (IPv4)
pihole | [✓] TCP (IPv4)
pihole | [✓] UDP (IPv6)
pihole | [✓] TCP (IPv6)
I stand corrected -- my docker logs pihole shows the same failure message that yours does.. but in my case, pihole is actually responding to DNS queries. So the logs indicate failure, but pihole is listening for DNS requests.
$ docker exec -ti pihole bash
root@pihole:/# grep :0035 /proc/net/tcp
2: 00000000:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 435453 1 0000000024bafaa7 100 0 0 10 5
(port 53 is 0x35)
OK I think I've gotten to the bottom of it. It's a race condition. Here's what startup looks like:
s6 cont-init.d/20-start.sh
-> /start.sh
-> test_configs
-> sudo -u ${DNSMASQ_USER:-root} pihole-FTL test || exit 1
According to the FTL src, "pihole-FTL test" performs a full startup, and then immediately exits. This is to confirm that the configs are valid. Then the s6 20-start.sh continues:
-> if gravity is *NOT* skipped on boot ($SKIPGRAVITYONBOOT), then:
-> gravity.sh
-> pihole status
-> looks for something listening on port 53, if it's not found (or if it's not pihole):
-> echo -e " ${CROSS} DNS service is NOT listening"
Perhaps in pihole <= 5.7, pihole-FTL test would fork and remain running (and listening on :53) long enough for gravity.sh to complete, so it got a clean pihole status at the end. but now, the FTL test process is gone by the time gravity's status check looks for a listener on port 53. Hence the error output.
Then 20-start.sh continues:
-> # Kill dnsmasq because s6 won't like it if it's running when s6 services start
kill -9 $(pgrep pihole-FTL) || true # TODO: REVISIT THIS SO AS TO NOT kill -9
-> prints "kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]"
This prints the kill usage because pgrep didn't find a pihole-FTL process. More evidence that this startup script expected pihole-FTL test to still be running by the time we got here.
Thanks for digging into this.. please join us in the discussion on Github:
If you have deleted or commented out the IP addresses in the setupvars, pihole -g returns the following error message:
"No IP addresses found! Please run 'pihole -r' to reconfigure".
Managed to get pi-hole running. It was failing to resolve DNS requests and was hanging on startup at the 'DNS service is NOT listening' message but by doing the following I have managed to get it running, although it still reports that message in the logs it does actually run. Steps taken:
- Stop v5.7 and download v5.8
- Completely delete all my existing configuration
- Start pi-hole container
- Login to the UI and re-enter all my settings
EDIT: Actually ignore that. It worked briefly until a reboot and then it's stopped working again and hangs on startup. Back to v5.7 for me.
After a bit of digging around I've got v5.8 running in Docker. It still shows the error message in the logs on startup, but it does actually run and resolve DNS requests. There's a bit of detail required here, but it's something that could easily affect other people so it's worth going over.
My network has a gateway that hands out IP addresses, DNS settings etc via DHCP (pretty standard) so this is the DNS server for my network and it forwards on requests to Pi-hole.
I have a small low power PC that runs Pi-hole in a docker container. This got it's address from a static reservation in the DHCP server. So at this point you have the scenario where the Pi-hole system is using the DHCP assigned DNS servers which are in turn itself.
During startup of the docker container it is trying to do some queries to the internet (looking for newer versions etc) which cannot work because there is no DNS server running because Pi-hole is not running. This in turn stops the docker container from starting up (or at the very least stall for a very long time).
I resolved this by setting a static IP and DNS etc on the server running the docker container so there is a way for DNS requests to work on the startup of the docker container.
BUT - this setup worked fine prior to the release of v5.8, so I think the comment about the startup changing and previously 'pihole-ftl test' being left running is true and this was allowing the startup to run previously.
It can be argued that I should have used a static IP on the server before, but controlling IPs through a single place on the gateway with reservations is much simpler to manage and it did work previously.
Either the docker container should avoid doing queries to the internet on startup before it is able to serve DNS requests or this situation should be documented so people can avoid it.
I did the upgrade, and am not using docker, but several hours after the upgrade my setup went to "DNS service is NOT listening". I was able to get this "fixed" temporarily by changing my DNS settings and saving, but I have noticed lots of database failure messages in the FTL log, for example here:
s ON network_addresses.network_id = network.id WHERE network_addresses.ip = ? AND interface != 'N/A' AND interface IS NOT NULL;] data (11)
[2021-04-16 10:46:00.746 823/T827] SQLite3 message: database corruption at line 67162 of [5d4c65779d] (11)
[2021-04-16 10:46:00.746 823/T827] SQLite3 message: statement aborts at 3: [SELECT MAX(ID) FROM queries] database disk image is malformed (11)
[2021-04-16 10:46:00.746 823/T827] Encountered step error in get_max_query_ID(): database disk image is malformed
[2021-04-16 10:46:00.747 823/T827] Error while trying to close database: database is locked
[2021-04-16 10:46:00.747 823/T827] Encountered error while trying to store queries in long-term database: database is locked
[2021-04-16 10:46:00.767 823/T827] ERROR: SQL query "DELETE FROM network_addresses WHERE lastSeen < 1587033960;" failed: database is locked
[2021-04-16 10:46:00.768 823/T827] Error while trying to close database: database is locked
[2021-04-16 10:46:00.768 823/T827] Error while trying to close database: database is locked
[2021-04-16 10:46:37.966 823M] SQLite3 message: database corruption at line 81887 of [5d4c65779d] (11)
[2021-04-16 10:46:37.966 823M] SQLite3 message: statement aborts at 25: [SELECT hwaddr FROM network WHERE id = (SELECT network_id FROM network_addresses WHERE ip = ? GROUP BY ip HAVING max(lastSeen));] database disk image is malformed (11)
[2021-04-16 10:46:37.967 823M] SQLite3 message: database corruption at line 81887 of [5d4c65779d] (11)
[2021-04-16 10:46:37.967 823M] SQLite3 message: statement aborts at 9: [SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;] database disk image is malformed (11)
[2021-04-16 10:46:37.968 823M] SQLite3 message: database corruption at line 81887 of [5d4c65779d] (11)
[2021-04-16 10:46:37.968 823M] SQLite3 message: statement aborts at 20: [SELECT name FROM network_addresses WHERE name IS NOT NULL AND network_id = (SELECT network_id FROM network_addresses WHERE ip = ?) ORDER BY lastSeen DESC LIMIT 1] database disk image i (11)
[2021-04-16 10:46:37.970 823M] SQLite3 message: database corruption at line 81887 of [5d4c65779d] (11)
[2021-04-16 10:46:37.970 823M] SQLite3 message: statement aborts at 10: [SELECT interface FROM network JOIN network_addresses ON network_addresses.network_id = network.id WHERE network_addresses.ip = ? AND interface != 'N/A' AND interface IS NOT NULL;] data (11)
[2021-04-16 10:47:00.846 823/T827] SQLite3 message: database corruption at line 67162 of [5d4c65779d] (11)
[2021-04-16 10:47:00.846 823/T827] SQLite3 message: statement aborts at 3: [SELECT MAX(ID) FROM queries] database disk image is malformed (11)
[2021-04-16 10:47:00.846 823/T827] Encountered step error in get_max_query_ID(): database disk image is malformed
[2021-04-16 10:47:00.846 823/T827] Error while trying to close database: database is locked
[2021-04-16 10:47:00.846 823/T827] Encountered error while trying to store queries in long-term database: database is locked
[2021-04-16 10:47:00.867 823/T827] ERROR: SQL query "DELETE FROM network_addresses WHERE lastSeen < 1587034020;" failed: database is locked
[2021-04-16 10:47:00.868 823/T827] Error while trying to close database: database is locked
[2021-04-16 10:47:00.868 823/T827] Error while trying to close database: database is locked
Open a new topic and fill out the template please.
1 Like
Having recently read about more hiccups related to the latest update I am wondering if there is some kind of "official" recommendation on how to proceed with installations not updated yet.
Should we wait - if so will there be any heads up on when it's good to proceed?
If not - is there any recommendation to minimize the risk of issues?
Thanks a lot for all the efforts!
I mean generally when we announce the release it's good to go. Obviously sometimes we miss things, it's just human nature.... but we try not to release more issues into the wild. You could always take a backup image of your SD card before updating so you have something to roll back to?
I totally agree - I hardly know anyone whose updates are as reliable as yours usually are. I'd wish all professional companies would deliver such a quality.
And yes, of course neither of us is perfect, that's perfectly fine - just wondering how to proceed in this particular case now.
Running a backup - the system is running from a SSD to avoid the well known SD card issues.
Downside of this is though that taking backups seems to be way less easier (SD card tools usually dont work with those, sizes are getting huge and it takes way more time).
Therefore I do not really want to shrug and just give it a try - while it seems that the risk might be higher currently...
There's an update for FTL that should be ready in a day or two so I guess you could hold off for that.
Thanks a lot for the advice! Highly appreciated! 
1 Like
This topic was automatically closed after 29 hours. New replies are no longer allowed.