Bug 7609 - Kernel change notify: poll() blocks indefinitely on FreeBSD
Kernel change notify: poll() blocks indefinitely on FreeBSD
Status: RESOLVED INVALID
Product: Samba 3.3
Classification: Unclassified
Component: File services
unspecified
x64 FreeBSD
: P3 critical
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-09 04:54 UTC by Leroy Raymond van Logchem
Modified: 2010-08-09 08:39 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 Leroy Raymond van Logchem 2010-08-09 04:54:03 UTC
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
Comment 1 Leroy Raymond van Logchem 2010-08-09 07:52:39 UTC
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.
Comment 2 Leroy Raymond van Logchem 2010-08-09 07:56:43 UTC
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.
Comment 3 Leroy Raymond van Logchem 2010-08-09 08:10:26 UTC
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 ()
Comment 4 Volker Lendecke 2010-08-09 08:39:45 UTC
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.