I recently came into this troube, when i use some acl edit script to update ACL information for the files hosted in samba server, the winbind server suddenly got panic, the related log file looks like this: [2006/04/21 18:24:02, 10] libsmb/smb_signing.c:simple_packet_signature(270) simple_packet_signature: sequence number 5112 [2006/04/21 18:24:02, 10] libsmb/smb_signing.c:client_sign_outgoing_message(340) client_sign_outgoing_message: sent SMB signature of [2006/04/21 18:24:02, 10] lib/util.c:dump_data(2075) [000] 88 E6 84 4E 8C 53 3F 27 ...N.S?' [2006/04/21 18:24:02, 10] libsmb/smb_signing.c:store_sequence_for_reply(74) store_sequence_for_reply: stored seq = 5113 mid = 2558 [2006/04/21 18:24:02, 6] libsmb/clientgen.c:write_socket(132) write_socket(23,194) [2006/04/21 18:24:02, 0] lib/util_sock.c:write_data(556) write_data: write failure. Error = Connection reset by peer [2006/04/21 18:24:02, 6] libsmb/clientgen.c:write_socket(135) write_socket(23,194) wrote -1 [2006/04/21 18:24:02, 0] libsmb/clientgen.c:write_socket(138) write_socket: Error writing 194 bytes to socket 23: ERRNO = Connection reset by peer [2006/04/21 18:24:02, 0] libsmb/clientgen.c:cli_send_smb(168) Error writing 194 bytes to client. -1 (Connection reset by peer) [2006/04/21 18:24:02, 10] libsmb/smb_signing.c:cli_signing_trans_stop(556) [2006/04/21 18:24:02, 0] lib/fault.c:fault_report(36) ==============================================================[2006/04/21 18:24:02, 0] lib/fault.c:fault_report(37) INTERNAL ERROR: Signal 11 in pid 19198 (3.0.20b-4vnf_01) Please read the Trouble-Shooting section of the Samba3-HOWTO [2006/04/21 18:24:02, 0] lib/fault.c:fault_report(39) From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf [2006/04/21 18:24:02, 0] lib/fault.c:fault_report(40) ==============================================================[2006/04/21 18:24:02, 0] lib/util.c:smb_panic2(1570) PANIC: internal error [2006/04/21 18:24:02, 0] lib/util.c:smb_panic2(1578) BACKTRACE: 18 stack frames: #0 /usr/sbin/winbindd(smb_panic2+0x128) [0x80da678] #1 /usr/sbin/winbindd(smb_panic+0x19) [0x80da549] #2 /usr/sbin/winbindd [0x80c720b] #3 /lib/i686/libc.so.6 [0x42028518] #4 /usr/sbin/winbindd(cli_receive_trans+0xc0) [0x81051a0] #5 /usr/sbin/winbindd [0x8136dc1] #6 /usr/sbin/winbindd(rpc_api_pipe_req_int+0x333) [0x81386e3] #7 /usr/sbin/winbindd(rpccli_lsa_lookup_sids+0x126) [0x8127046] #8 /usr/sbin/winbindd(msrpc_sid_to_name+0xd2) [0x8088f72] #9 /usr/sbin/winbindd [0x807e3df] #10 /usr/sbin/winbindd(winbindd_lookup_name_by_sid+0x56) [0x807a596] #11 /usr/sbin/winbindd(winbindd_getgrgid+0x15d) [0x8076cad] #12 /usr/sbin/winbindd(strftime+0x1599) [0x8072611] #13 /usr/sbin/winbindd(strftime+0x17c1) [0x8072839] #14 /usr/sbin/winbindd(strftime+0x2662) [0x80736da] #15 /usr/sbin/winbindd(main+0x4a5) [0x8073bc5] #16 /lib/i686/libc.so.6(__libc_start_main+0xc7) [0x42015967] #17 /usr/sbin/winbindd(ldap_msgfree+0x89) [0x8071e11] Ater tracing the related src, I think it might be a bug in libsmb/smb_signing.c:cli_signing_trans_stop, when log level is set to 10, it will log the trans_info like below, DEBUG(10,("cli_signing_trans_stop: freeing mid = %u, reply_seq_num %u, send_seq_num = %u \ data->send_seq_num = %u\n", (unsigned int)data->trans_info->mid, (unsigned int)data->trans_info->reply_seq_num, (unsigned int)data->trans_info->send_seq_num, (unsigned int)data->send_seq_num )); I guess when client connect is reset by peer, trans_info will no longer be available so the DEBUG will cause seg fault and winbind will get panic, is that correct? I wish anybody could help me to confirm this, if this is true, I'd like to fire a bug.
Jeremy Allison
2006-Apr-25 08:01 UTC
[Samba] [3.0.20b]connection reset caused winbind to panic
On Tue, Apr 25, 2006 at 03:57:09PM +0900, Hui Wang wrote:> I recently came into this troube, when i use some acl edit script to update > ACL information for the files hosted in samba server, the winbind server > suddenly got panic, the related log file looks like this:Can you please try and reproduce this with the 3.0.23 pre release please. That will let us know if the bug has already been fixed. Jeremy.