[Samba] Samba panics frequently after being configured for AD authentication

Sun Mar 17 10:25:17 MDT 2013

(Sorry for the top post.  I did not want to lose the details below)

Today, at 5:10am local time the panics started again.  This time, they are in clusters 10 minutes apart.  Each cluster has from one to a couple dozen panics a few seconds apart.  I have core dumps enabled again and as long as the frequency stays reasonable, I will keep it that way.

In looking at the /var/log/samba directory, it appears the machine triggering these panics might be named mydomain-s01.  At least that is the file name holding all the panic message in that directory.

Please let me know what I can do to track down this problem and make it stop.

TIA

Chris Kukuchka
Sequoia Group, Inc.

On Mar 15, 2013, at 10:25 AM, Chris Kukuchka <chrisk at sequoiagroup.com> wrote:

> On Mar 14, 2013, at 3:57 AM, Volker Lendecke wrote:
> 
>> On Wed, Mar 13, 2013 at 02:13:47PM -0600, Chris Kukuchka wrote:
>>> Hello,
>>> 
>>> I had just completed reconfiguring Samba so it would
>>> authenticate against Active Directory.  After user side
>>> testing seemed successful, I found the log directory on
>>> the server was growing quickly and abrtd emails were being
>>> sent out.  Unfortunately, I have been unable to track down
>>> the cause for these panics and I am looking for help.
>> 
>> If you happen to have one of the core files left, can you
>> get us a full backtrace ("bt full" in gdb) with symbols, so
>> that we can see the line numbers and local variables? You
>> might have to install debuginfo RPMs for Samba.
> 
> Thank you so much for your reply.  I apologize for not posting back sooner, but I wanted to be certain what I was seeing.
> 
> After making my configuration change, Samba was panicking several times a minute.  To prevent filling up the filesystem, I turned off core dumps and removed all the core files.  This panics continued from Mar 13 13:21 to  Mar 14 06:03 and then stopped completed.  At this time (Mar 15 11:16), no further panics have happened.
> 
> Luckily, sosreport kept a couple core dump files.  Here is the requested backtrace:
> 
> Core was generated by `smbd -D'.
> Program terminated with signal 6, Aborted.
> #0  0x00007f02396648a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64      return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0  0x00007f02396648a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1  0x00007f0239666085 in abort () at abort.c:92
> #2  0x00007f023cce2e31 in dump_core () at lib/fault.c:391
> #3  0x00007f023ccf2869 in smb_panic (why=<value optimized out>) at lib/util.c:1133
> #4  0x00007f023cce32b4 in fault_report (sig=11) at lib/fault.c:53
> #5  sig_fault (sig=11) at lib/fault.c:76
> #6  <signal handler called>
> #7  0x00007f023cb61844 in _wkssvc_NetWkstaEnumUsers (p=<value optimized out>, r=<value optimized out>)
>   at rpc_server/wkssvc/srv_wkssvc_nt.c:591
> #8  0x00007f023cb606f7 in api_wkssvc_NetWkstaEnumUsers (p=0x7f023e84baf0) at librpc/gen_ndr/srv_wkssvc.c:209
> #9  0x00007f023cbe54b6 in api_rpcTNP (p=0x7f023e84baf0, pkt=0x7f023e843ed0, api_rpc_cmds=0x7f023d4689c0, 
>   n_cmds=<value optimized out>) at rpc_server/srv_pipe.c:1647
> #10 0x00007f023cbe672f in api_pipe_request (p=0x7f023e84baf0) at rpc_server/srv_pipe.c:1580
> #11 process_request_pdu (p=0x7f023e84baf0) at rpc_server/srv_pipe.c:1837
> #12 process_complete_pdu (p=0x7f023e84baf0) at rpc_server/srv_pipe.c:1894
> #13 0x00007f023cbe7ea8 in process_incoming_data (p=0x7f023e84baf0, data=0x7f023e85d020 "D", n=<value optimized out>)
>   at rpc_server/srv_pipe_hnd.c:218
> #14 0x00007f023cbe8341 in write_to_internal_pipe (mem_ctx=<value optimized out>, ev=0x7f023e82d4f0, handle=<value optimized out>, 
>   data=<value optimized out>, len=92) at rpc_server/srv_pipe_hnd.c:244
> #15 np_write_send (mem_ctx=<value optimized out>, ev=0x7f023e82d4f0, handle=<value optimized out>, data=<value optimized out>, 
>   len=92) at rpc_server/srv_pipe_hnd.c:538
> #16 0x00007f023c9d7f79 in api_dcerpc_cmd (conn=0x7f023e844b00, vuid=<value optimized out>, req=<value optimized out>, 
>   setup=<value optimized out>, data=<value optimized out>, params=<value optimized out>, suwcnt=2, tdscnt=92, tpscnt=0, 
>   mdrcnt=1024, mprcnt=0) at smbd/ipc.c:271
> #17 api_fd_reply (conn=0x7f023e844b00, vuid=<value optimized out>, req=<value optimized out>, setup=<value optimized out>, 
>   data=<value optimized out>, params=<value optimized out>, suwcnt=2, tdscnt=92, tpscnt=0, mdrcnt=1024, mprcnt=0)
>   at smbd/ipc.c:482
> #18 0x00007f023c9d847b in named_pipe (conn=0x7f023e844b00, req=0x7f023e85ceb0, state=0x7f023e846c10) at smbd/ipc.c:537
> #19 handle_trans (conn=0x7f023e844b00, req=0x7f023e85ceb0, state=0x7f023e846c10) at smbd/ipc.c:594
> #20 0x00007f023c9d92ea in reply_trans (req=0x7f023e85ceb0) at smbd/ipc.c:779
> #21 0x00007f023ca41604 in switch_message (type=37 '%', req=0x7f023e85ceb0, size=180) at smbd/process.c:1574
> #22 0x00007f023ca41a1b in construct_reply (sconn=0x7f023e82d5b0, inbuf=<value optimized out>, nread=180, unread_bytes=0, 
>   seqnum=<value optimized out>, encrypted=false, deferred_pcd=0x0) at smbd/process.c:1610
> #23 process_smb (sconn=0x7f023e82d5b0, inbuf=<value optimized out>, nread=180, unread_bytes=0, seqnum=<value optimized out>, 
>   encrypted=false, deferred_pcd=0x0) at smbd/process.c:1688
> #24 0x00007f023ca41e35 in smbd_server_connection_read_handler (conn=0x7f023e82d5b0, fd=27) at smbd/process.c:2318
> #25 0x00007f023cd01ad7 in run_events_poll (ev=0x7f023e82d4f0, pollrtn=<value optimized out>, pfds=0x7f023e844670, num_pfds=2)
>   at lib/events.c:286
> #26 0x00007f023ca3f97d in smbd_server_connection_loop_once (sconn=0x7f023e82d5b0) at smbd/process.c:1017
> #27 smbd_process (sconn=0x7f023e82d5b0) at smbd/process.c:3159
> #28 0x00007f023cf628cf in smbd_accept_connection (ev=<value optimized out>, fde=<value optimized out>, 
>   flags=<value optimized out>, private_data=<value optimized out>) at smbd/server.c:514
> #29 0x00007f023cd01ad7 in run_events_poll (ev=0x7f023e82d4f0, pollrtn=<value optimized out>, pfds=0x7f023e846e40, num_pfds=5)
>   at lib/events.c:286
> #30 0x00007f023cd01f8f in s3_event_loop_once (ev=0x7f023e82d4f0, location=<value optimized out>) at lib/events.c:349
> #31 0x00007f023cd02310 in _tevent_loop_once (ev=0x7f023e82d4f0, location=0x7f023d16d929 "smbd/server.c:820")
>   at ../lib/tevent/tevent.c:494
> #32 0x00007f023cf63bcb in smbd_parent_loop (argc=<value optimized out>, argv=0x7f023e851450) at smbd/server.c:820
> #33 main (argc=<value optimized out>, argv=0x7f023e851450) at smbd/server.c:1304
> 
> HTH
> 
> Chris Kukuchka
> Sequoia Group, Inc.
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba