You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On setups where this limit is high, this takes a large amount of time - or even "hangs" indefinitely. Docker sets this limit to ~1M for instance - and the kubernetes setup I am using (k3s) is setting it to "Infinity", which translates to 1073741816.
Work around is to run a ulimit -n 1024 before starting FTL in the container - but that's not really a clean solution. (ie add command: [ sh, -c, ulimit -n 1024 && /s6-init ] in the k8s container)
Any modification to the dnsmasq code needs to be imported from the upstream project to avoid deviations inevitably leading to merge conflicts down the road.
Please contact Simon Kelley over the dnsmasq mailing list for this issue, I'm sure he will have something to say about this: [email protected]
As soon as the dnsmasq projects adopts a code, we can discuss cherry-picking it into our code even before the change is released for the official dnsmasq release.
Just a quick heads up: The code has already landed in FTL (e26f786) and is currently waiting in update/dnsmasq for merging into release/v5.0 when dnsmasq v2.81 is released.
In raising this issue, I confirm the following (please check boxes, eg [X]) Failure to fill the template will close your issue:
How familiar are you with the codebase?:
1
[BUG | ISSUE]
On startup, FTL tries to close all file descriptors from 0 to
ulimit -n
(the maximum number of open files) - here https://github.com/pi-hole/FTL/blob/master/dnsmasq/dnsmasq.c#L149On setups where this limit is high, this takes a large amount of time - or even "hangs" indefinitely. Docker sets this limit to ~1M for instance - and the kubernetes setup I am using (k3s) is setting it to "Infinity", which translates to
1073741816
.I would suggest switching over to something based on the actually open files - like was done for the rpm package: cf https://bugzilla.redhat.com/show_bug.cgi?id=1537564 and https://github.com/rpm-software-management/rpm/pull/444/files for an actual patch
Work around is to run a
ulimit -n 1024
before starting FTL in the container - but that's not really a clean solution. (ie addcommand: [ sh, -c, ulimit -n 1024 && /s6-init ]
in the k8s container)Might be related to pi-hole/docker-pi-hole#561 - I think I was hitting that issue as well
Device specifics
Hardware Type: k3s - kubernetes 1.17 / docker 19.03.6-ce
The text was updated successfully, but these errors were encountered: