Bug 2638 - smbd PANIC - internal error
Summary: smbd PANIC - internal error
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.14a
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-22 05:03 UTC by A. Bitz
Modified: 2005-10-04 04:50 UTC (History)
0 users

See Also:


Attachments
smb.conf (1.23 KB, text/plain)
2005-04-25 00:09 UTC, A. Bitz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description A. Bitz 2005-04-22 05:03:44 UTC
Server with Suse 9.2 and samba-3.0.14-0.1 (rpm)

Everything is working, the following message appears sometimes in my logs, smbd
keeps running...

smbd[17958]: [2005/04/21 12:02:13, 0] lib/fault.c:fault_report(36)
smbd[17958]:   ===============================================================
smbd[17958]: [2005/04/21 12:02:13, 0] lib/fault.c:fault_report(37)
smbd[17958]:   INTERNAL ERROR: Signal 11 in pid 17958 (3.0.14-0.1-SUSE)
smbd[17958]:   Please read the appendix Bugs of the Samba HOWTO collection
smbd[17958]: [2005/04/21 12:02:13, 0] lib/fault.c:fault_report(39)
smbd[17958]:   ===============================================================
smbd[17958]: [2005/04/21 12:02:13, 0] lib/util.c:smb_panic2(1495)
smbd[17958]:   PANIC: internal error
smbd[17958]: [2005/04/21 12:02:13, 0] lib/util.c:smb_panic2(1503)
smbd[17958]:   BACKTRACE: 30 stack frames:
smbd[17958]:    #0 /usr/sbin/smbd(smb_panic2+0x120) [0x820c4d0]
smbd[17958]:    #1 /usr/sbin/smbd(smb_panic+0x26) [0x820c6a6]
smbd[17958]:    #2 /usr/sbin/smbd [0x81f7070]
smbd[17958]:    #3 [0xffffe420]
smbd[17958]:    #4 /lib/tls/libc.so.6 [0xb7d31ff4]
smbd[17958]:    #5 /lib/tls/libc.so.6 [0xb7d322e2]
smbd[17958]:    #6 /lib/tls/libc.so.6(getpwnam_r+0x14d) [0xb7cd3bed]
smbd[17958]:    #7 /lib/tls/libc.so.6(getpwnam+0x91) [0xb7cd35b1]
smbd[17958]:    #8 /usr/sbin/smbd(sys_getpwnam+0x1d) [0x81f9ddd]
smbd[17958]:    #9 /usr/sbin/smbd(getpwnam_alloc+0x5a) [0x81feb0a]
smbd[17958]:    #10 /usr/sbin/smbd(Get_Pwnam+0x15f) [0x81fcbdf]
smbd[17958]:    #11 /usr/sbin/smbd(smb_getpwnam+0x83) [0x8252fa3]
smbd[17958]:    #12 /usr/sbin/smbd [0x82531da]
smbd[17958]:    #13 /usr/sbin/smbd(make_server_info_info3+0x168) [0x8253438]
smbd[17958]:    #14 /usr/sbin/smbd [0x824f347]
smbd[17958]:    #15 /usr/sbin/smbd [0x824f80c]
smbd[17958]:    #16 /usr/sbin/smbd [0x824d492]
smbd[17958]:    #17 /usr/sbin/smbd [0x8249860]
smbd[17958]:    #18 /usr/sbin/smbd [0x8254713]
smbd[17958]:    #19 /usr/sbin/smbd [0x811d49e]
smbd[17958]:    #20 /usr/sbin/smbd(ntlmssp_update+0x15c) [0x811cc7c]
smbd[17958]:    #21 /usr/sbin/smbd(auth_ntlmssp_update+0x4b) [0x825439b]
smbd[17958]:    #22 /usr/sbin/smbd [0x80b57b9]
smbd[17958]:    #23 /usr/sbin/smbd(reply_sesssetup_and_X+0x4fa) [0x80b6aaa]
smbd[17958]:    #24 /usr/sbin/smbd [0x80e11e0]
smbd[17958]:    #25 /usr/sbin/smbd(process_smb+0x19a) [0x80e179a]
smbd[17958]:    #26 /usr/sbin/smbd(smbd_process+0x16f) [0x80e1bff]
smbd[17958]:    #27 /usr/sbin/smbd(main+0x530) [0x82904e0]
smbd[17958]:    #28 /lib/tls/libc.so.6(__libc_start_main+0xe0) [0xb7c62b10]
smbd[17958]:    #29 /usr/sbin/smbd [0x807a391]
Comment 1 Volker Lendecke 2005-04-22 06:11:23 UTC
Do you have nss_ldap or something like that running? Could you please attach your smb.conf?  Can you relate that segfault to any specific user or action? Maybe you could increase the debug level moderately and create machine-individual log files with 'log file = /var/log/samba/log.%m' and nail it down to specific machines.  Volker 
Comment 2 A. Bitz 2005-04-25 00:09:43 UTC
Created attachment 1170 [details]
smb.conf

I removed the lot of our Shares, the settings are all the same as in the
example.
Comment 3 A. Bitz 2005-04-25 00:10:24 UTC
(In reply to comment #1) 
> Do you have nss_ldap or something like that running?  
 
No, I don't. The server is a simple member of our old NT-Domain. 
 
> Can you relate that segfault to any specific user or action? Maybe you could 
increase the debug level moderately and create machine-individual log files 
with 'log file = /var/log/samba/log.%m' and nail it down to specific machines.   
 
I already use individual logfiles. :-) The problem occured 3 times in 3 days, 
always caused by different machines. 
 
In one logfile I found directly before the panic the following entry: 
"rpc_client/cli_pipe.c:cli_nt_session_open(1451) 
  cli_nt_session_open: cli_nt_create failed on pipe \lsarpc to machine 
MEMODC02. -> our PDC 
  Error was NT_STATUS_PIPE_NOT_AVAILABLE" 
 
In another log I found (directly before the panic, too): 
"smbd/nttrans.c:call_nt_transact_ioctl(2317) 
  call_nt_transact_ioctl(0x90028): Currently not implemented." 
 
The third panic is without anything interesting. 
 
I don't think, this ist belonging to the problem, for it's always different, 
but perhaps it can help you? 
 
I attached my smb.conf. 
 
 
Comment 4 A. Bitz 2005-04-27 00:33:09 UTC
The problems remain, I get at least one smb panic per Day... Here the last one:

smbd[18739]: [2005/04/27 09:18:03, 0] lib/fault.c:fault_report(36)
smbd[18739]:   ===============================================================
smbd[18739]: [2005/04/27 09:18:03, 0] lib/fault.c:fault_report(37)
smbd[18739]:   INTERNAL ERROR: Signal 11 in pid 18739 (3.0.14a-0.1-SUSE)
smbd[18739]:   Please read the appendix Bugs of the Samba HOWTO collection
smbd[18739]: [2005/04/27 09:18:03, 0] lib/fault.c:fault_report(39)
smbd[18739]:   ===============================================================
smbd[18739]: [2005/04/27 09:18:03, 0] lib/util.c:smb_panic2(1495)
smbd[18739]:   PANIC: internal error
Apr 27 09:18:03 superserver smbd[18739]: [2005/04/27 09:18:03, 0]
lib/util.c:smb_panic2(1503)
smbd[18739]:   BACKTRACE: 30 stack frames:
smbd[18739]:    #0 /usr/sbin/smbd(smb_panic2+0x120) [0x820c3e0]
smbd[18739]:    #1 /usr/sbin/smbd(smb_panic+0x26) [0x820c5b6]
smbd[18739]:    #2 /usr/sbin/smbd [0x81f6f90]
smbd[18739]:    #3 [0xffffe420]
smbd[18739]:    #4 /lib/tls/libc.so.6 [0xb7d31ff4]
smbd[18739]:    #5 /lib/tls/libc.so.6 [0xb7d322e2]
smbd[18739]:    #6 /lib/tls/libc.so.6(getpwnam_r+0x14d) [0xb7cd3bed]
smbd[18739]:    #7 /lib/tls/libc.so.6(getpwnam+0x91) [0xb7cd35b1]
smbd[18739]:    #8 /usr/sbin/smbd(sys_getpwnam+0x1d) [0x81f9cfd]
smbd[18739]:    #9 /usr/sbin/smbd(getpwnam_alloc+0x5a) [0x81fea2a]
smbd[18739]:    #10 /usr/sbin/smbd(Get_Pwnam+0x15f) [0x81fcaff]
smbd[18739]:    #11 /usr/sbin/smbd(smb_getpwnam+0x83) [0x8252e53]
smbd[18739]:    #12 /usr/sbin/smbd [0x825308a]
smbd[18739]:    #13 /usr/sbin/smbd(make_server_info_info3+0x168) [0x82532e8]
smbd[18739]:    #14 /usr/sbin/smbd [0x824f1f7]
smbd[18739]:    #15 /usr/sbin/smbd [0x824f6bc]
smbd[18739]:    #16 /usr/sbin/smbd [0x824d342]
smbd[18739]:    #17 /usr/sbin/smbd [0x8249710]
smbd[18739]:    #18 /usr/sbin/smbd [0x82545c3]
smbd[18739]:    #19 /usr/sbin/smbd [0x811d42e]
smbd[18739]:    #20 /usr/sbin/smbd(ntlmssp_update+0x15c) [0x811cc0c]
smbd[18739]:    #21 /usr/sbin/smbd(auth_ntlmssp_update+0x4b) [0x825424b]
smbd[18739]:    #22 /usr/sbin/smbd [0x80b5799]
smbd[18739]:    #23 /usr/sbin/smbd(reply_sesssetup_and_X+0x4fa) [0x80b6a8a]
smbd[18739]:    #24 /usr/sbin/smbd [0x80e11a0]
smbd[18739]:    #25 /usr/sbin/smbd(process_smb+0x19a) [0x80e175a]
smbd[18739]:    #26 /usr/sbin/smbd(smbd_process+0x16f) [0x80e1bbf]
smbd[18739]:    #27 /usr/sbin/smbd(main+0x530) [0x8290330]
smbd[18739]:    #28 /lib/tls/libc.so.6(__libc_start_main+0xe0) [0xb7c62b10]
smbd[18739]:    #29 /usr/sbin/smbd [0x807a391]
Comment 5 Volker Lendecke 2005-04-27 01:33:10 UTC
Ways to get closer to this:

Increase the debug level and send us a higher debug output from before the
crash. I doubt that this really gives us hints, but you never know.

Try to catch an smbd when it's crashed. I always do this with

panic action = "/bin/sleep 90000"

You might call a shell script here that notifies you somehow by sending mail or
so. Then you could attach to that one with gdb and print out the local variables.

This assumes that you know how to work with gdb, sorry.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-10-04 04:50:48 UTC
This should be fixed in 3.0.20