Crashes in bind9 name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001))
Hi,
After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued.
This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace
bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison.
Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.
If anybody here on the list has an idea, then please let me know.
Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9
Stack trace: Stack trace of thread 6432: #0 0x00007fb5a348b94c __pthread_kill_implementation (libc.so.6 + 0x8b94c) #1 0x00007fb5a343e646 raise (libc.so.6 + 0x3e646) #2 0x00007fb5a34287f3 abort (libc.so.6 + 0x287f3) #3 0x00005570cbbea5b5 assertion_failed.cold (named + 0x1c5b5) #4 0x00007fb5a433d420 isc_assertion_failed (libisc-9.16.23-RH.so + 0x1c420) #5 0x00007fb5a409f9ca dns_name_equal (libdns-9.16.23-RH.so + 0x9f9ca) #6 0x00007fb5a40b48ec dns_order_find (libdns-9.16.23-RH.so + 0xb48ec) #7 0x00007fb5a4429de8 query_addrrset.lto_priv.0 (libns-9.16.23-RH.so + 0x1dde8) #8 0x00007fb5a442eece query_gotanswer (libns-9.16.23-RH.so + 0x22ece) #9 0x00007fb5a4432b8b fetch_callback (libns-9.16.23-RH.so + 0x26b8b) #10 0x00007fb5a43781bd isc_task_run (libisc-9.16.23-RH.so + 0x571bd) #11 0x00007fb5a43632a9 process_netievent (libisc-9.16.23-RH.so + 0x422a9) #12 0x00007fb5a4363425 process_queue (libisc-9.16.23-RH.so + 0x42425) #13 0x00007fb5a4363c17 async_cb (libisc-9.16.23-RH.so + 0x42c17) #14 0x00007fb5a4285afd uv__async_io.part.0 (libuv.so.1 + 0xaafd) #15 0x00007fb5a42a185e uv__io_poll.part.0 (libuv.so.1 + 0x2685e) #16 0x00007fb5a428b568 uv_run (libuv.so.1 + 0x10568) #17 0x00007fb5a43634db nm_thread (libisc-9.16.23-RH.so + 0x424db) #18 0x00007fb5a4375f9a isc__trampoline_run (libisc-9.16.23-RH.so + 0x54f9a) #19 0x00007fb5a3489c02 start_thread (libc.so.6 + 0x89c02) #20 0x00007fb5a350ec40 __clone3 (libc.so.6 + 0x10ec40)
Hi,
On Fri, Nov 1, 2024 at 3:51 PM Kees Bakker via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi,
After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued.
This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace
bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison.
Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.
The issue has already been reported here: https://issues.redhat.com/browse/RHEL-30407
If anybody here on the list has an idea, then please let me know.
Some more details Version info:
- os: CentOS 9-Stream
- ipa packages 4.12.0-4.el9
- bind9 packages 32:9.16.23-15.el9
- bind-libdyndb-ldap 11.9.8-el9
Some updates are available for those packages, it may be worth trying.
flo
Stack trace: Stack trace of thread 6432: #0 0x00007fb5a348b94c __pthread_kill_implementation (libc.so.6 + 0x8b94c) #1 0x00007fb5a343e646 raise (libc.so.6 + 0x3e646) #2 0x00007fb5a34287f3 abort (libc.so.6 + 0x287f3) #3 0x00005570cbbea5b5 assertion_failed.cold (named + 0x1c5b5) #4 0x00007fb5a433d420 isc_assertion_failed (libisc-9.16.23-RH.so + 0x1c420) #5 0x00007fb5a409f9ca dns_name_equal (libdns-9.16.23-RH.so + 0x9f9ca) #6 0x00007fb5a40b48ec dns_order_find (libdns-9.16.23-RH.so + 0xb48ec) #7 0x00007fb5a4429de8 query_addrrset.lto_priv.0 (libns-9.16.23-RH.so + 0x1dde8) #8 0x00007fb5a442eece query_gotanswer (libns-9.16.23-RH.so + 0x22ece) #9 0x00007fb5a4432b8b fetch_callback (libns-9.16.23-RH.so + 0x26b8b) #10 0x00007fb5a43781bd isc_task_run (libisc-9.16.23-RH.so + 0x571bd) #11 0x00007fb5a43632a9 process_netievent (libisc-9.16.23-RH.so + 0x422a9) #12 0x00007fb5a4363425 process_queue (libisc-9.16.23-RH.so + 0x42425) #13 0x00007fb5a4363c17 async_cb (libisc-9.16.23-RH.so + 0x42c17) #14 0x00007fb5a4285afd uv__async_io.part.0 (libuv.so.1 + 0xaafd) #15 0x00007fb5a42a185e uv__io_poll.part.0 (libuv.so.1 + 0x2685e) #16 0x00007fb5a428b568 uv_run (libuv.so.1 + 0x10568) #17 0x00007fb5a43634db nm_thread (libisc-9.16.23-RH.so + 0x424db) #18 0x00007fb5a4375f9a isc__trampoline_run (libisc-9.16.23-RH.so + 0x54f9a) #19 0x00007fb5a3489c02 start_thread (libc.so.6 + 0x89c02) #20 0x00007fb5a350ec40 __clone3 (libc.so.6 + 0x10ec40) -- Kees -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 04-11-2024 12:56, Florence Blanc-Renaud wrote:
Hi,
On Fri, Nov 1, 2024 at 3:51 PM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi, After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued. This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison. Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.The issue has already been reported here: https://issues.redhat.com/browse/RHEL-30407
Even though I have a subscription, I don't have permission to view it. :-(
If anybody here on the list has an idea, then please let me know. Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9Some updates are available for those packages, it may be worth trying.
I will give that a try. Thanks.
On 04-11-2024 12:56, Florence Blanc-Renaud wrote:
Hi,
On Fri, Nov 1, 2024 at 3:51 PM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi, After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued. This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison. Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.The issue has already been reported here: https://issues.redhat.com/browse/RHEL-30407
If anybody here on the list has an idea, then please let me know. Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9Some updates are available for those packages, it may be worth trying.
Nope. With the latest CentOS 9-Stream packages it is also crashing at startup.
Version info: * ipa packages: 4.12.2-1.el9 * bind packages: 32:9.16.23-24.el9 * bind-libdyndb-ldap: 11.9-10.el9
The only thing for me to do is to keep retrying to start named until it finally stays up and running.
It would help if I knew a little bit more what is in that RHEL-30407 issue.
Kees Bakker via FreeIPA-users wrote:
On 04-11-2024 12:56, Florence Blanc-Renaud wrote:
Hi,
On Fri, Nov 1, 2024 at 3:51 PM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi,
After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued.
This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace
bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison.
Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.
The issue has already been reported here: https://issues.redhat.com/browse/RHEL-30407
If anybody here on the list has an idea, then please let me know.
Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9
Some updates are available for those packages, it may be worth trying.
Nope. With the latest CentOS 9-Stream packages it is also crashing at startup.
Version info:
- ipa packages: 4.12.2-1.el9
- bind packages: 32:9.16.23-24.el9
- bind-libdyndb-ldap: 11.9-10.el9
The only thing for me to do is to keep retrying to start named until it finally stays up and running.
It would help if I knew a little bit more what is in that RHEL-30407 issue.
It probably wouldn't. There are some stack traces there with a similar assertion failure but no solutions yet. If you want to provide a stack trace we could confirm it is identical but in the end it would just be "yup, same thing" and still wouldn't be that helpful.
The bind developer has been looking into it but the root cause has been elusive.
rob
On 06-11-2024 13:59, Rob Crittenden wrote:
Kees Bakker via FreeIPA-users wrote:
On 04-11-2024 12:56, Florence Blanc-Renaud wrote:
Hi,
On Fri, Nov 1, 2024 at 3:51 PM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hi, After a scheduled power down on and power up on one of our IPA servers named crashed. I remember I saw this before and that it was "solved" by restarting named. This time however it took about 12 retries before named finally continued. This is the error it produces ../../../lib/dns/name.c:667: REQUIRE((name1->attributes & 0x00000001) == (name2->attributes & 0x00000001)) failed, back trace bind9 is quite drastic when it hits a failing REQUIRE. It immediately stops with a coredump. But it doesn't tell which names are failing the comparison. Of course I can (or should) report this to the bind developers. However, I'm sure they are going to say that this is an old version and that I should ask CentOS/RH devs.The issue has already been reported here: https://issues.redhat.com/browse/RHEL-30407
If anybody here on the list has an idea, then please let me know. Some more details Version info: * os: CentOS 9-Stream * ipa packages 4.12.0-4.el9 * bind9 packages 32:9.16.23-15.el9 * bind-libdyndb-ldap 11.9.8-el9Some updates are available for those packages, it may be worth trying.
Nope. With the latest CentOS 9-Stream packages it is also crashing at startup.
Version info:
- ipa packages: 4.12.2-1.el9
- bind packages: 32:9.16.23-24.el9
- bind-libdyndb-ldap: 11.9-10.el9
The only thing for me to do is to keep retrying to start named until it finally stays up and running.
It would help if I knew a little bit more what is in that RHEL-30407 issue.
It probably wouldn't. There are some stack traces there with a similar assertion failure but no solutions yet. If you want to provide a stack trace we could confirm it is identical but in the end it would just be "yup, same thing" and still wouldn't be that helpful.
The bind developer has been looking into it but the root cause has been elusive.
rob
When you said "bind developer", did you mean someone from RedHat, or someone from the Bind ISC community?
The reason I ask is that I have now a debug environment setup where I can run gdb and break at the point where it hits the assertion_failed. The problem is, I have to make sense of what I'm looking at. I want to get advice from a bind developer how to print information, for example,
(gdb) up #3 0x00007ffff7cb4adc in match (name2=0x7fffd8650010, name1=0x7fff8ccf5010) at ../../../lib/dns/order.c:96 96 return (dns_name_equal(name1, name2)); (gdb) p *name1 $1 = {magic = 1145983854, ndata = 0x7fff8ccec010 "", length = 0, labels = 0, attributes = 0, offsets = 0x7fff8ccf5068 "", buffer = 0x0, link = {prev = 0x0, next = 0x0}, list = {head = 0x7fff8cb71c50, tail = 0x7fff8cb71c50}, ht = 0x0}
How can I see the actual name from this? That's the question I would ask.
freeipa-users@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Kees Bakker -
Rob Crittenden