On Sat, 29 Jun 2024 12:11:32 -0500
Samba via samba <samba at lists.samba.org> wrote:
> Michael,
>
> Thanks for doing the backtrace.? I would have needed a lot of
> instruction.
>
> Dale
>
> On 06/28/2024 3:12 AM, Michael Tokarev via samba wrote:
> > On 6/28/24 08:16, Douglas Bagnall wrote:
> >
> >> And yes, a backtrace will help.
> >
> >
> > $ gdb /usr/sbin/named
> > GNU gdb (Debian 13.2-1+b2) 13.2
> >
> > (gdb) ru -4 -d10 -n1 -f -p54 -L /dev/stdout
> > Starting program: /usr/sbin/named -4 -d10 -n1 -f -p54 -L /dev/stdout
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> > "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > [New Thread 0x7ffff3b7f680 (LWP 546107)]
> >
> > Thread 1 "named" received signal SIGSEGV, Segmentation
fault.
> > 0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> >
> > (gdb) bt
> > #0? 0x00007ffff6f35340 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > #1? 0x00007ffff6f35669 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> > #2? 0x00007ffff6f37e2f in free () from
> > /lib/x86_64-linux-gnu/libc.so.6 #3? 0x00007ffff13e1155 in ?? ()
> > from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
> > #4? 0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0,
> > reference_ctx=0x7ffff4235d20) at
> > source4/dsdb/schema/schema_set.c:896 #5? 0x00007ffff13e0d5c in ??
> > () from /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
> > #6? 0x00007ffff463f2c2 in ldb_module_init_chain () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #7? 0x00007ffff463f2c2 in ldb_module_init_chain () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #8? 0x00007ffff143cdd4 in ?? () from
> > /usr/lib/x86_64-linux-gnu/samba/ldb/rootdse.so
> > #9? 0x00007ffff463f2c2 in ldb_module_init_chain () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #10 0x00007ffff1410f13 in ?? () from
> > /usr/lib/x86_64-linux-gnu/samba/ldb/samba_dsdb.so
> > #11 0x00007ffff463f2c2 in ldb_module_init_chain () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #12 0x00007ffff463f3ac in ldb_load_modules () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #13 0x00007ffff463e2be in ldb_connect () from
> > /lib/x86_64-linux-gnu/libldb.so.2
> > #14 0x00007ffff2455435 in samba_ldb_connect
> > (ldb=ldb at entry=0x7ffff4288fe0, lp_ctx=lp_ctx at
entry=0x7ffff3cd8720,
> > ??? url=url at entry=0x7ffff43fa960
> > "/var/lib/samba/bind-dns/dns/sam.ldb", flags=flags at
entry=64) at
> > lib/ldb-samba/ldb_wrap.c:230
> > #15 0x00007ffff321a678 in samdb_connect_url
> > (mem_ctx=mem_ctx at entry=0x7ffff4277de0, ev_ctx=0x7ffff42b1720,
> > lp_ctx=0x7ffff3cd8720,
> > ??? session_info=0x7ffff3cd8a20, flags=64, flags at entry=0,
> > url=url at entry=0x7ffff43fa960
"/var/lib/samba/bind-dns/dns/sam.ldb",
> > ??? remote_address=0x0, ldb_ret=0x7ffff4277df0,
> > errstring=0x7fffffff8be0) at source4/dsdb/samdb/samdb.c:96
> > #16 0x00007ffff47aba6e in dlz_create (dlzname=<optimized out>,
> > argc=1, argv=0x7ffff42ec288, dbdata=0x7ffff42776a8)
> > ??? at source4/dns_server/dlz_bind9.c:741
> > #17 0x0000555555579126 in ?? ()
> > #18 0x00007ffff7b4f49a in ?? () from
> > /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
> > #19 0x00007ffff7a5b105 in dns_dlzcreate () from
> > /lib/x86_64-linux-gnu/libdns-9.19.25-185-g392e7199df2-1-Debian.so
> > #20 0x000055555558cf07 in ?? ()
> > #21 0x000055555559d88f in ?? ()
> > #22 0x000055555559eb81 in ?? ()
> > #23 0x00007ffff7c6e537 in isc.async_cb () from
> > /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
> > #24 0x00007ffff737cd33 in ?? () from
> > /lib/x86_64-linux-gnu/libuv.so.1 #25 0x00007ffff7390a72 in ?? ()
> > from /lib/x86_64-linux-gnu/libuv.so.1 #26 0x00007ffff737d9f8 in
> > uv_run () from /lib/x86_64-linux-gnu/libuv.so.1 #27
> > 0x00007ffff7c81850 in ?? () from
> > /lib/x86_64-linux-gnu/libisc-9.19.25-185-g392e7199df2-1-Debian.so
> > #28 0x000055555556e97a in main ()
> >
> > (gdb) frame 3
> > #3? 0x00007ffff13e1155 in ?? () from
> > /usr/lib/x86_64-linux-gnu/samba/ldb/schema_load.so
> >
> > (gdb) frame 4
> > #4? 0x00007ffff245a82b in dsdb_get_schema (ldb=0x7ffff4288fe0,
> > reference_ctx=0x7ffff4235d20) at
> > source4/dsdb/schema/schema_set.c:896 896??????????????? schema_out
> > = refresh_fn(loaded_from_module, (gdb) l
> > 891??????????? /* We need to guard against recursive calls here */
> > 892??????????? if (ldb_set_opaque(ldb,
"dsdb_schema_refresh_fn",
> > NULL) != LDB_SUCCESS) {
> > 893??????????????? ldb_debug_set(ldb, LDB_DEBUG_FATAL,
> > 894????????????????????????? "dsdb_get_schema: clearing
> > dsdb_schema_refresh_fn failed");
> > 895??????????? } else {
> > 896??????????????? schema_out = refresh_fn(loaded_from_module,
> > 897??????????????????????????? ldb_get_event_context(ldb),
> > 898??????????????????????????? schema_in,
> > 899??????????????????????????? use_global_schema);
> > 900??????????? }
> >
> > Smells like the stack is damaged..
>
>
OK, see bug https://bugzilla.samba.org/show_bug.cgi?id=15643
Where Michael Saxl has identified the problem and provided a workaround.
Seemingly you need to set an environmental variable
LDB_MODULES_DISABLE_DEEPBIND
The easiest way I found to do this was to create a systemd override file
systemctl edit named.service
Add (where it tells you to):
[Service]
Environment="LDB_MODULES_DISABLE_DEEPBIND=1"
Save and close the file.
Now start Bind9
systemctl start named.service
It should work.
Rowland