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
On 7/1/24 11:16 AM, Rowland Penny via samba wrote:> 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 bughttps://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. > > RowlandThanks, Rowland.? It did work, although I can't say I know what I did - even after reading through the bug report. ? Assuming this is eventually fixed, will the override file cause problems at that time? Thanks, again. Dale
On 7/1/24 11:16 AM, Rowland Penny via samba wrote:> 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 bughttps://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. > > RowlandThanks, Rowland.? It did work, although I can't say I know what I did - even after reading through the bug report. ? Assuming this is eventually fixed, will the override file cause problems at that time? Thanks, again. Dale