DL6ER
July 20, 2020, 3:48am
21
DL6ER:
We can do this.
This will be included in Pi-hole FTL v5.1.1 through
pi-hole:release/v5.1.1 ← pi-hole:fix/sqlite_concurrent_TCP_termination_crash
opened 07:03PM - 19 Jul 20 UTC
**By submitting this pull request, I confirm the following:**
- [X] I have re… ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md).
- [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist.
- [X] I have considered, and confirmed that this submission will be valuable to others.
- [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
- [X] I give this submission freely, and claim no ownership to its content.
**How familiar are you with the codebase?:**
## 10
---
We've seen reports where connection termination due to timeout and foreign client disconnecting can happen at the same time (on milliseconds accuracy). The detailed bug description can be found in https://github.com/pi-hole/FTL/issues/816#issuecomment-660013854.
We're performing four changes in this pull request:
1. We skip second termination if there is already a termination event in progress. This ensures that a running termination cannot be interrupted. To ensure non-interruptibility, we use C11 atomic functions ensuring we generate atomic test code.
2. In addition to step 1, we try to ensure that this situation does not even happen by doubling the TCP worker timeout from 105 seconds to 300 seconds
3. Increase limit for concurrently active TCP workers from 20 to 60.
We've seen reports where 20 wasn't sufficient in user networks. Given that TCP workers do not really consume all that much more memory, this limit may even be increased further in case we recognize that 60 still isn't sufficient.
4. For debugging proposes, we show for which TCP worker FTL created a fork.
Previously:
```
TCP worker forked
```
Now:
```
TCP worker forked for client 192.168.0.15 on interface enp0s2 (192.168.0.11)
```
1 Like
Thank you! The issue I was having seems to have stopped. With the 5.1 release, I switched back to the master branch (and lost the status_checking fix), but I'm no longer accumulating so many TCP workers so fast. I also updated cloudflared (which is acting as my upstream DNS server). In about 24 hours of uptime, I still only have one pihole-FTL PID.
I'm glad pihole is working well again, but I don't know if an update fixed it or if the device on my network making all the TCP requests just stopped.
Thanks again for all of the troubleshooting, @DL6ER !
system
August 11, 2020, 11:26pm
23
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.