- User Since
- Jul 31 2022, 1:52 AM (17 w, 2 d)
Sat, Nov 12
I seem to have jumped the gun a bit as the issue seems to have been resolved via:
@c-po I think the reason you're seeing the old name of 'pdns-r/worker' is due to a packaging regression described in T4814. All the latest builds of vyos 1.4 seem to be providing powerdns 4.4 instead of the expected 4.8. Since this issue and corresponding bugfix only pertains to powerdns >= 4.8, the issue would not be visible if powerdns is downgraded to 4.4.
Just as a point of additional reference, I've bisected the PowerDNS source code to see where the change from 'pdns-r/worker' to something else occurred and successfully found that commit 69b39198 in the repository changes the thread names away from the prefix of 'pdns-r'. Since that change, the string pdns-r/ no longer exists in the source code. The aforementioned commit is included in the following tags:
Thu, Nov 10
Hmm, I can't seem to reproduce that name with "pdns-recursor/now 4.8.0~beta1-1pdns.bullseye amd64" or "pdns-recursor/now 4.8.0~beta2-1pdns.bullseye amd64" both in a live bare-metal system or in a VM. Both versions return pdns_recursor for me when printed from p.name(). The worker thread names (as listed from ps or htop) also don't match: "rec/web+stat" and "rec/taskThread", not that either of these are returned by p.name().
Wed, Nov 9
@c-po I noticed you've reverted the commit, may I ask how you're able to reproduce the process name of 'pdns-r/worker'? Just doing the testing again with the latest build as of writing (vyos-1.4-rolling-202211060813-amd64.iso), I get:
Sat, Nov 5
Thu, Nov 3
A patch to the WIDE DHCPv6 client seems to be sufficient to resolve this issue with respect to the way VyOS currently uses the daemon (one daemon per configured interface), PRs below:
Oct 19 2022
Oct 4 2022
Sep 26 2022
It seems like I was wrong about the netfilter rule not working as intended (and in my testing the clamp was broken for some other reason that was an error on my part), the post has been edited to only indicate the remaining issue of an overly strict MSS clamping range.
Sep 24 2022
See https://unix.stackexchange.com/questions/672742/why-mss-clamping-in-iptables-nft-seems-to-take-no-effect-in-nftables for additional explanation why the iptables version do not work under iptables-nft.
Sep 11 2022
Sep 10 2022
Sep 9 2022
Sep 6 2022
Sep 5 2022
The smoketest seems suspect, the error line has nothing to do with this issue and running the smoketest several times results in tests passing/failing arbitrarily on that line (across multiple tests).