Platform: FreeBSD 8.1-RELEASE Package : binary added Samba (/usr/ports/net/samba33 by timur@FreeBSD.org) Symptoms: After successful connect, browse a folder doesn't return the list of files but user has to wait at least 30 seconds ( up to 90 ). Then the list is shown like normal. On the server has appeared a smbd which uses 100% cpu and does not exit anymore. Tracing the system calls shows endless calls to poll(18,<something>). Workaround: Set "kernel change notify = No", restart Samba and problem was gone. Environment: amd64 using ZFS v14 filesystem without ACL's
Ahum, the workaround didn't work, it happened again. truss -p <pid of the 100% cpu smbd> gives the following line repeated endless: poll({18/POLLIN|POLLPRI|POLLERR|POLLHUP},1,-1) = 1 (0x1) When the user disconnects the smbd stays alive and is visible in smbstatus.
The file descriptor 18 when seen using fstat -p <pid of the 100% cpu smbd>: root smbd <pid> 18* internet stream tcp ffffff01d6435708 0 rw I hope this helps. Any tips on debugging this are welcome.
I managed to attach gdb to the 100% cpu smbd and did a backtrace: #0 0x000000080198c7bc in poll () from /lib/libc.so.7 #1 0x00000008017df85e in poll () from /lib/libthr.so.3 #2 0x0000000800bfaf47 in ldap_result () from /usr/local/lib/libldap-2.4.so.7 #3 0x000000080202575d in _nss_ldap_next_entry () from /usr/local/lib/nss_ldap.so.1 #4 0x0000000802025996 in _nss_ldap_ent_context_release () from /usr/local/lib/nss_ldap.so.1 #5 0x0000000802028585 in _nss_ldap_endgrent () from /usr/local/lib/nss_ldap.so.1 #6 0x000000080192c34e in __nss_compat_endgrent () from /lib/libc.so.7 #7 0x00000008019bab13 in nsdispatch () from /lib/libc.so.7 #8 0x00000008019881c7 in setgrent () from /lib/libc.so.7 #9 0x00000008019babbb in nsdispatch () from /lib/libc.so.7 #10 0x0000000801987c6b in getgrnam () from /lib/libc.so.7 #11 0x00000000006bb98f in sys_getgrouplist () #12 0x00000000006bba46 in getgroups_unix_user () #13 0x00000000006ec270 in create_token_from_username () #14 0x00000000006ecbda in create_local_token () #15 0x00000000006f00a4 in auth_ntlmssp_check_password () #16 0x0000000000518055 in ntlmssp_server_auth () #17 0x000000000051788f in ntlmssp_update () #18 0x00000000006efd9a in auth_ntlmssp_update () #19 0x00000000004ad427 in reply_sesssetup_and_X_spnego () #20 0x00000000004ad7cd in reply_sesssetup_and_X () #21 0x00000000004dee5f in switch_message () #22 0x00000000004e12d6 in smbd_process () #23 0x00000000008c0484 in main ()
This *VERY* much looks like a problem in nss_ldap or the lower-level LDAP libraries. Samba is calling into getgrnam (get a group entry). You might want to try reproducing the issue without samba by calling something like "getent group <groupname>" for all groups in sequence. One of the groups should make the command hang in the same way smbd is hanging. I'm closing this as INVALID. Please re-open if after this explanation you think this is still a bug that can be solved from within the Samba project.