Coro
July 2, 2020, 7:44am
16
Does this now work? It certainly works for me in a very quick test:
Concerning the latter, that might be a false-positive, they opened a PR to fix this yesterday:
pi-hole:development
← pi-hole:fix/status_checking
opened 04:45PM - 01 Jul 20 UTC
**By submitting this pull request, I confirm the following:**
- [X] I have r… ead and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template.
- [X] I have made only one major change in my proposed changes.
- [X] I have commented my proposed changes within the code.
- [X] I have tested my proposed changes, and have included unit tests where possible.
- [X] I am willing to help maintain this change if there are issues with it later.
- [X] I give this submission freely and claim no ownership.
- [X] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
- [X] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
---
**What does this PR aim to accomplish?:**
The current test can fail even when there is no error i case the max. number of TCP workers is reached.
**How does this PR accomplish the above?:**
Actually test if there is a `pihole*` process running on port 53. If so, analyze if we bound to IPv4/6 and UDP/TCP. If all four sockets are accepting/listening, we report that the DNS service is running. If some are missing, we report this, too. If no `pihole*` process is listening on port 53, then this is the new (better) criterion for saying: it is not running
Example for when everything is fine:
```
$ pihole status
[✓] DNS service is listening
[✓] Pi-hole blocking is enabled
```
When, e.g., IPv6 is not available:
```
$ pihole status
[✗] DNS service is partially listening
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✗] UDP (IPv6)
[✗] TCP (IPv6)
[✓] Pi-hole blocking is enabled
```
Or, when FTL is offline:
```
$ pihole status
[✗] DNS service is NOT listening
```
**What documentation changes (if any) are needed to support this PR?:**
None
Ah, this reminds me of a discussion I've seen on Github yesterday, let's go into this more:
Yes, this:
This very much sounds like this (link to a specific comment in there, also from yesterday):
opened 02:44PM - 24 Jun 20 UTC
closed 09:23PM - 11 Aug 20 UTC
Bug
```
[2020-06-22 19:49:47.166 1937] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!… !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-06-22 19:49:47.166 1937] ----------------------------> FTL crashed! <----------------------------
[2020-06-22 19:49:47.166 1937] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-06-22 19:49:47.166 1937] Please report a bug at https://github.com/pi-hole/FTL/issues
[2020-06-22 19:49:47.166 1937] and include in your report already the following details:
[2020-06-22 19:49:47.166 1937] FTL has been running for 8821 seconds
[2020-06-22 19:49:47.166 1937] FTL branch: fix/fhriley-fix_buf_overflow
[2020-06-22 19:49:47.166 1937] FTL version: vDev-3c0553e
[2020-06-22 19:49:47.166 1937] FTL commit: 3c0553e
[2020-06-22 19:49:47.166 1937] FTL date: 2020-06-18 19:33:27 +0200
[2020-06-22 19:49:47.167 1937] FTL user: started as pihole, ended as pihole
[2020-06-22 19:49:47.167 1937] Compiled for armhf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
[2020-06-22 19:49:47.167 1937] Received signal: Segmentation fault
[2020-06-22 19:49:47.167 1937] at address: 0x59
[2020-06-22 19:49:47.167 1937] with code: SEGV_MAPERR (Address not mapped to object)
[2020-06-22 19:49:47.168 1937] Backtrace:
[2020-06-22 19:49:47.169 1937] B[0000]: 0x4768d6, /usr/bin/pihole-FTL(+0x258d6) [0x4768d6]
[2020-06-22 19:49:47.407 1937] L[0000]: /root/project/src/signals.c:94
[2020-06-22 19:49:47.416 1937] B[0001]: 0x76e16130, /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0x76e16130]
[2020-06-22 19:49:47.416 1937] B[0002]: 0x4bcf7e, /usr/bin/pihole-FTL(+0x6bf7e) [0x4bcf7e]
[2020-06-22 19:49:47.605 1937] L[0002]: /root/project/src/database/sqlite3.c:27530
[2020-06-22 19:49:47.621 1937] B[0003]: 0x4cac92, /usr/bin/pihole-FTL(+0x79c92) [0x4cac92]
[2020-06-22 19:49:47.777 1937] L[0003]: /root/project/src/database/sqlite3.c:80717
[2020-06-22 19:49:47.793 1937] B[0004]: 0x4f8f3c, /usr/bin/pihole-FTL(+0xa7f3c) [0x4f8f3c]
[2020-06-22 19:49:47.949 1937] L[0004]: /root/project/src/database/sqlite3.c:80751
[2020-06-22 19:49:47.965 1937] B[0005]: 0x4f9010, /usr/bin/pihole-FTL(sqlite3_finalize+0x37) [0x4f9010]
[2020-06-22 19:49:48.120 1937] L[0005]: /root/project/src/database/sqlite3.c:27946
[2020-06-22 19:49:48.137 1937] B[0006]: 0x47bdd6, /usr/bin/pihole-FTL(+0x2add6) [0x47bdd6]
[2020-06-22 19:49:48.157 1937] L[0006]: /root/project/src/database/gravity-db.c:490
[2020-06-22 19:49:48.159 1937] B[0007]: 0x48b942, /usr/bin/pihole-FTL(+0x3a942) [0x48b942]
[2020-06-22 19:49:48.183 1937] L[0007]: /root/project/src/dnsmasq/dnsmasq.c:1254
[2020-06-22 19:49:48.188 1937] B[0008]: 0x76e16120, /lib/arm-linux-gnueabihf/libc.so.6(__default_sa_restorer+0) [0x76e16120]
[2020-06-22 19:49:48.188 1937] B[0009]: 0x4f9044, /usr/bin/pihole-FTL(sqlite3_finalize+0x6b) [0x4f9044]
[2020-06-22 19:49:48.397 1937] L[0009]: /root/project/src/database/sqlite3.c:25801
[2020-06-22 19:49:48.414 1937] B[0010]: 0x47bdd6, /usr/bin/pihole-FTL(+0x2add6) [0x47bdd6]
[2020-06-22 19:49:48.434 1937] L[0010]: /root/project/src/database/gravity-db.c:490
[2020-06-22 19:49:48.436 1937] B[0011]: 0x48b796, /usr/bin/pihole-FTL(+0x3a796) [0x48b796]
[2020-06-22 19:49:48.460 1937] L[0011]: /root/project/src/dnsmasq/dnsmasq.c:1981
[2020-06-22 19:49:48.463 1937] B[0012]: 0x48ca50, /usr/bin/pihole-FTL(main_dnsmasq+0xc07) [0x48ca50]
[2020-06-22 19:49:48.487 1937] L[0012]: /root/project/src/dnsmasq/dnsmasq.c:1206
[2020-06-22 19:49:48.489 1937] B[0013]: 0x46c740, /usr/bin/pihole-FTL(main+0xa7) [0x46c740]
[2020-06-22 19:49:48.507 1937] L[0013]: /root/project/src/main.c:95
[2020-06-22 19:49:48.509 1937] B[0014]: 0x76e00718, /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x10c) [0x76e00718]
[2020-06-22 19:49:48.509 1937] ------ Listing content of directory /dev/shm ------
[2020-06-22 19:49:48.509 1937] File Mode User:Group Filesize Filename
[2020-06-22 19:49:48.510 1937] rwxrwxrwx root:root 260 .
[2020-06-22 19:49:48.510 1937] rwxr-xr-x root:root 4K ..
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 4K FTL-per-client-regex
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 16K FTL-dns-cache
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 29K FTL-overTime
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 1M FTL-queries
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 20K FTL-upstreams
[2020-06-22 19:49:48.510 1937] rw------- pihole:pihole 324K FTL-clients
[2020-06-22 19:49:48.511 1937] rw------- pihole:pihole 66K FTL-domains
[2020-06-22 19:49:48.511 1937] rw------- pihole:pihole 53K FTL-strings
[2020-06-22 19:49:48.511 1937] rw------- pihole:pihole 12 FTL-settings
[2020-06-22 19:49:48.511 1937] rw------- pihole:pihole 124 FTL-counters
[2020-06-22 19:49:48.511 1937] rw------- pihole:pihole 28 FTL-lock
[2020-06-22 19:49:48.511 1937] ---------------------------------------------------
[2020-06-22 19:49:48.511 1937] Thank you for helping us to improve our FTL engine!
[2020-06-22 19:49:48.511 1937] FTL terminated!
```
_Originally posted by @JohnstonCode in https://github.com/pi-hole/FTL/issues/770#issuecomment-648663985_
TL;DR: Pi-hole imposes an upper limit of 20 concurrently running TCP workers at the same time as measure against a resource-exhaustion attack (after all, many Pi-hole are reachable from the public Internet, even when this is really not a good idea).
I checked git blame
and this limit has always (at least since 2004) been there and is unchanged. Given the substantial improvement in memory and computing power since 2004, rising this limit is likely necessary!
@webdevelopers Maybe you want to increase the limit of concurrently allowed TCP connections from 20 to something substantially larger?
When more and more (I can only assume IoT) devices use "steady" TCP connections for their DNS, this seems a necessity. dnsmasq
(and hence Pi-hole) rejects new TCP connections when the maximum number is reached . This doesn't seem to be the proper way of things (even when I understand why this is technically).