Hi Ondřej!
I play around with eu-stack. When I call eu-stack -p 1605200 -v (during normal
operations) the stacktrace looks meaningless to me (See below). Do I need a
certain parameter or do I have to install debug symbols?
Thanks
Klaus
# eu-stack -p 1605200 -v
PID 1605200 - process
TID 160520
On 06. 09. 24 9:04, Klaus Darilion via bind-users wrote:
I play around with eu-stack. When I call eu-stack -p 1605200 -v (during
normal operations) the stacktrace looks meaningless to me (See below).
Do I need a certain parameter or do I have to install debug symbols?
Seems fine to me - you j
Yup, you need dbgsym packages?
https://ubuntu.com/server/docs/debug-symbol-packages
https://wiki.ubuntu.com/DebuggingProgramCrash#Installing_dbgsym_packages_from_a_PPA
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply
I just happened again. I have not yet installed the debug symbols.
I query the SOA every second with 1 second timeout. Here are the traces. I
happened a few times in a row.
Below are the traces.
I noticed the timeout happened during Bind9 starting an inbound IXFR:
Sep 06 07:20:55 named[1605200]
Yes, just replace RPZ with “processing the incoming transfers”.Sounds like 12 should work in your case.We should have a fix ready in couple of weeks.Ondrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal
As there just was another IXFR, for the records, here is another trace with
debug symbols installed. Thanks
Klaus
PID 1605200 - process
TID 1605200:
#0 0x7b8ceb529ee0 epoll_pwait - /usr/lib/x86_64-linux-gnu/libc.so.6
#1 0x7b8cec52c9fa - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#
From: Ondřej Surý
Sent: Friday, September 6, 2024 4:10 PM
To: Klaus Darilion
Cc: Klaus Darilion via bind-users
Subject: Re: Sporadic Timeouts after upgrading to bind9.20
Hmm, what is the churn in the zones? How often there’s IXFR and how large those
changes are?
Every 30 minutes. See logs:
This one was accidentially not sent to the list, sorry!
On Thu, Sep 05, 2024 at 08:04:37PM +0200, Ondřej Surý wrote:
! I’m on my phone, so this is a long shot, but you can try disabling the qname
minimization.
Thank You for the suggestion, I can try this occasionally. Rather
I'd prefer to figure
Recently (2024/9/21) I ran into an issue that might be similar. Due to
DDoS attacks that use complicated lookups to make DNS servers do extra
work, to slow them down, some recent DNS server software has tightened the
amount of 'work' that it will do on a single query before giving up and
returning
On Fri, Sep 06, 2024 at 12:55:20PM -0400, Bob Harold wrote:
! Recently (2024/9/21) I ran into an issue that might be similar. Due to
! DDoS attacks that use complicated lookups to make DNS servers do extra
! work, to slow them down, some recent DNS server software has tightened the
! amount of 'wo
Try using running `named -d 9 (plus other existing args)` to see why there are
31+ queries. There must be something wonky going on.
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
>
On Fri, Sep 06, 2024 at 08:05:18PM +0200, Ondřej Surý wrote:
! Try using running `named -d 9 (plus other existing args)` to see why there
are 31+ queries. There must be something wonky going on.
!
Alright. "-d 9" does nothing.
Changing the named.conf does something:
channel named_log {
Now the question remains - why? I don’t really see a reason for this behavior
from where I tested it, so what is the traffic between your recursor and the
Internet during the time this happens?
Ondřej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please
Ok, so according to zonemaster:
https://zonemaster.net/en/result/7fc39ff8fc1766ac all the nameservers are in
the same zone. I am guessing that any intermittent failure can cause a lot of
outgoing queries.
Anyway - since you are hitting the 32 limit, perhaps bumping the limit to 100
(the value
The original zone has NS records in two domains:
t-ipnet.de. 82632 IN NS dns20.dns.t-ipnet.de.
t-ipnet.de. 82632 IN NS dns02.dns.t-ipnet.de.
t-ipnet.de. 82632 IN NS dns00.dns.t-ipnet.de.
t-ipnet.de. 82632 IN NS pns.dtag.de.
t-ipnet.de. 82632 IN NS dns50.dns.t-ipnet.de.
And dtag.de has:
dtag.de. 61
On Fri, Sep 06, 2024 at 09:12:51PM +0200, Ondřej Surý wrote:
! Now the question remains - why? I don’t really see a reason for this
! behavior from where I tested it, so what is the traffic between your
! recursor and the Internet during the time this happens?
Well, I can see why - but I don't kno
From: Ondřej Surý
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion
Cc: Petr Špaček ; bind-users@lists.isc.org; Klaus Darilion via
bind-users
Subject: Re: Sporadic Timeouts after upgrading to bind9.20
Are your running with options { reuseport no; }; ?
You might want to try that.
A
Correcting myself: event with { reuseport no; }; and UV_THREADPOOL_SIZE=12
still timeouts happen, but the situation improved a lot.
Regards
Klaus
From: bind-users On Behalf Of Klaus Darilion
via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý
Cc: Klaus Darilion via bind-
18 matches
Mail list logo
