Samba (namly winbindd in 4.6.x releases and SMB2 locks in newer releases) hangs sporadicly A backtrace of the locked up winbindd process shows: #0 0x00007f8eb6cf52a2 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #1 0x00007f8eaf962b3e in ?? () from /usr/lib64/libtdb.so.1 For an upstream bug report I got the suggestion: Can you try "dbwrap_tdb_mutexes:*=no" in the [global] section. Maybe your kernel/glibc has a broken implementation of robust mutexs. See https://bugzilla.redhat.com/show_bug.cgi?id=1401665 Running the Test Case V2 it shows that glibc-2.25-r11 (which is the latest unmasked version) seems to suffer from a broken robust mutexes implementation (I think upstream fixed it not before glibc-2.26). It seems that tdb 1.3.15 (and probably earlier) uses them by default unless the option mentioned above is inserted into smb.conf (which seems to be undocumented (at least man smb.conf doesn't tell you anything about it - the Samba 4.2.x release notes note that this option can be set manually to yes (haven't found the release notes where it became the default))). I think there should be an info in the Samba ebuild at the end of the build process that adding this option could be very important to prevent lockups (unless the robust mutexes bugfixes are being backported to glibc-2.25 or glibc-2.26 (which hopefully contains the necessary fixes) is being unmasked (should probably happen next month according to the glibc-2.26 unmask bug request)).
> Running the Test Case V2 it shows that glibc-2.25-r11 (which is the latest > unmasked version) seems to suffer from a broken robust mutexes > implementation (I think upstream fixed it not before glibc-2.26). We're going to stabilize glibc-2.26 pretty soon (meaning, beginning of June), so a backport to glibc-2.25 is fairly unlikely.
2.26 is stable, 2.25 is masked now.
