Bug 3769 - smbd process locks and hogs CPU on FreeBSD/AMD64 w. LDAP backend
Summary: smbd process locks and hogs CPU on FreeBSD/AMD64 w. LDAP backend
Status: RESOLVED INVALID
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.22
Hardware: x64 FreeBSD
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-10 08:18 UTC by Andrea Venturoli
Modified: 2011-03-21 19:18 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea Venturoli 2006-05-10 08:18:57 UTC
Occasionally users will find their files on the server are locked and can't be deleted/modified/moved.
Server side analysis shows a single smbd process hogging one CPU and holding the file(s), which cannot be killed unless "kill -9" is used.
I've heard other users with the same problems and we all have SMP systems. It is not clear wether this would happen on UP systems too.

Stack backtrace (below) shows this is LDAP related.



#0  0x000000080113fcbc in select () from /lib/libc.so.6
#1  0x00000008009a4e5c in ldap_int_select (ld=0x8e7900, timeout=0x0) at os-ip.c:750
#2  0x000000080098defc in wait4msg (ld=0x8e7900, msgid=1, all=1, timeout=0x0, result=0x7fffffffcf70) at result.c:331
#3  0x000000080098d945 in ldap_result (ld=0x8e7900, msgid=1, all=1, timeout=0x0, result=0x7fffffffcf70) at result.c:126
#4  0x0000000800994dd9 in ldap_sasl_bind_s (ld=0x8e7900, dn=0x8f27a0 "cn=root,dc=biolchim,dc=in", mechanism=0x0, cred=0x7fffffffcfd0,
    sctrls=0x0, cctrls=0x0, servercredp=0x0) at sasl.c:207
#5  0x000000080099571c in ldap_simple_bind_s (ld=0x8e7900, dn=0x8f27a0 "cn=root,dc=biolchim,dc=in", passwd=0x8e85b0 "Samskeyti")
    at sbind.c:126
#6  0x00000000006cfce8 in smbldap_connect_system (ldap_state=0x8c3450, ldap_struct=0x8e7900) at lib/smbldap.c:880
#7  0x00000000006d01f7 in smbldap_open (ldap_state=0x8c3450) at lib/smbldap.c:960
#8  0x00000000006d049b in another_ldap_try (ldap_state=0x8c3450, rc=0x7fffffffd230, attempts=0x7fffffffd22c, endtime=1147156482)
    at lib/smbldap.c:1037
#9  0x00000000006d08ef in smbldap_search_ext (ldap_state=0x8c3450, base=0x8d3bd0 "dc=biolchim,dc=in", scope=2,
    filter=0x7fffffffd350 "(&(rid=3011)(objectclass=sambaAccount))", attrs=0x8e7800, attrsonly=0, sctrls=0x0, cctrls=0x0, sizelimit=0,
    res=0x7fffffffd908) at lib/smbldap.c:1126
#10 0x00000000006d0a1d in smbldap_search (ldap_state=0x8c3450, base=0x8d3bd0 "dc=biolchim,dc=in", scope=2,
    filter=0x7fffffffd350 "(&(rid=3011)(objectclass=sambaAccount))", attrs=0x8e7800, attrsonly=0, res=0x7fffffffd908) at lib/smbldap.c:1150
#11 0x00000000006d1561 in smbldap_search_suffix (ldap_state=0x8c3450, filter=0x7fffffffd350 "(&(rid=3011)(objectclass=sambaAccount))",
    search_attr=0x8e7800, result=0x7fffffffd908) at lib/smbldap.c:1339
#12 0x00000000005f3b9f in ldapsam_search_suffix_by_rid (ldap_state=0x8c3350, rid=3011, result=0x7fffffffd908, attr=0x8e7800)
    at passdb/pdb_ldap.c:370
#13 0x00000000005f7587 in ldapsam_get_ldap_user_by_sid (ldap_state=0x8c3350, sid=0x8d3498, result=0x7fffffffd908) at passdb/pdb_ldap.c:1537
#14 0x00000000005f75f7 in ldapsam_getsampwsid (my_methods=0x8ba850, user=0x8f1c50, sid=0x8d3498) at passdb/pdb_ldap.c:1560
#15 0x00000000005ea2e1 in context_getsampwsid (context=0x8ba650, sam_acct=0x8f1c50, sid=0x8d3498) at passdb/pdb_interface.c:222
#16 0x00000000005ed11f in pdb_getsampwsid (sam_acct=0x8f1c50, sid=0x8d3498) at passdb/pdb_interface.c:1095
#17 0x00000000005e5ecc in local_sid_to_uid (puid=0x8d34e4, psid=0x8d3498, name_type=0x7fffffffda2c) at passdb/passdb.c:1188
#18 0x00000000005f1e69 in sid_to_uid (psid=0x8d3498, puid=0x8d34e4) at passdb/lookup_sid.c:430
#19 0x00000000004b8ba3 in create_canon_ace_lists (fsp=0x8e7300, pst=0x7fffffffe190, pfile_owner_sid=0x7fffffffe140,
    pfile_grp_sid=0x7fffffffe0f0, ppfile_ace=0x7fffffffe020, ppdir_ace=0x7fffffffe018, dacl=0x8c14d0) at smbd/posix_acls.c:1393
#20 0x00000000004b9c3e in unpack_canon_ace (fsp=0x8e7300, pst=0x7fffffffe190, pfile_owner_sid=0x7fffffffe140, pfile_grp_sid=0x7fffffffe0f0,
    ppfile_ace=0x7fffffffe0e8, ppdir_ace=0x7fffffffe0e0, security_info_sent=7, psd=0x8e7550) at smbd/posix_acls.c:1943
#21 0x00000000004bdef7 in set_nt_acl (fsp=0x8e7300, security_info_sent=7, psd=0x8e7550) at smbd/posix_acls.c:3183
#22 0x00000000004b3c1a in vfswrap_fset_nt_acl (handle=0x0, fsp=0x8e7300, fd=-1, security_info_sent=7, psd=0x8e7550) at smbd/vfs-wrap.c:842
#23 0x000000000046e597 in set_sd (fsp=0x8e7300, data=0x8e7400 "\001", sd_len=176, security_info_sent=7) at smbd/nttrans.c:1041
#24 0x000000000047219c in call_nt_transact_set_security_desc (conn=0x8f0050, inbuf=0x8f7000 "", outbuf=0x918000 "", length=264,
    bufsize=131072, ppsetup=0x7fffffffe420, setup_count=0, ppparams=0x7fffffffe430, parameter_count=8, ppdata=0x7fffffffe428,
    data_count=176, max_data_count=0) at smbd/nttrans.c:2093
#25 0x000000000047438d in reply_nttrans (conn=0x8f0050, inbuf=0x8f7000 "", outbuf=0x918000 "", length=264, bufsize=131072)
    at smbd/nttrans.c:2981
#26 0x00000000004c428f in switch_message (type=160, inbuf=0x8f7000 "", outbuf=0x918000 "", size=264, bufsize=131072) at smbd/process.c:1071
#27 0x00000000004c4366 in construct_reply (inbuf=0x8f7000 "", outbuf=0x918000 "", size=264, bufsize=131072) at smbd/process.c:1101
#28 0x00000000004c473e in process_smb (inbuf=0x8f7000 "", outbuf=0x918000 "") at smbd/process.c:1201
#29 0x00000000004c5a34 in smbd_process () at smbd/process.c:1753
#30 0x00000000006d5248 in main (argc=4, argv=0x7fffffffe810) at smbd/server.c:976
Comment 1 Gerald (Jerry) Carter (dead mail address) 2006-05-10 08:38:13 UTC
Looks (and sounds) like a bug in the OpenLDAP client libs.
Comment 2 Björn Jacke 2011-03-21 19:18:08 UTC
really doesn't look like a smbd bug. please reopen if you still see this bug on current 3.5 samba versions and with current ldap libs. in that case please attach log level 10, too.