I have a difficult-to-track-down bug that refuses to let itself be reproduced
easily, and yet it occurs every couple of days, with around 10 active clients.
From time to time the client smbd process panics, and from that point on it is
no longer possible to print. Stopping and restarting the smbd service clears the
The stack trace is as follows:
BACKTRACE: 14 stack frames:
#0 smbd(smb_panic+0x11c) [0x81c3aac]
#1 smbd [0x81b21e2]
#2 /lib/tls/libc.so.6 [0x420277b8]
#3 smbd(print_queue_status+0x156) [0x81e13b6]
#4 smbd [0x808cace]
#5 smbd(api_reply+0x196) [0x80932f6]
#6 smbd(reply_trans+0x54b) [0x808a6ab]
#7 smbd [0x80c8466]
#8 smbd [0x80c8639]
#9 smbd(process_smb+0x8f) [0x80c884f]
#10 smbd(smbd_process+0x167) [0x80c9497]
#11 smbd(main+0x4bf) [0x822fa9f]
#12 /lib/tls/libc.so.6(__libc_start_main+0xe4) [0x42015704]
#13 smbd(ldap_msgfree+0x8d) [0x8076f21]
I had similar problems when using CUPS for printing, both natively and BSD
style. We thought CUPS was the problem, so we pulled that out and installed
lprng to provide printing services.
User authentication is performed with OpenLDAP 2.0.27. The Linux distribution is
Red Hat Linux release 9 (Shrike).
I have placed the client log file (debug level=10) and the smb.conf with the
activity several seconds prior to the segfault at the following location:
Seems this bug is related to Bug 1147.
Try updating to 3.0.3pre1 or recompile Samba 3.0.2a plus the patch attached to
*** This bug has been marked as a duplicate of 1147 ***
Created attachment 9712 [details]
The content of attachment 9712 [details] has been deleted by
Björn Jacke <firstname.lastname@example.org>
who provided the following reason:
The token used to delete this attachment was generated at 2014-02-24 10:54:45 UTC.