[Samba] Samba 4 AD DC 100% cpu process issues.

[Eric Kingston]

Hello,

We had a bad experience with Samba 4 AD DC on FreeBSD 9.2 Release 
recently that I thought I would share on this mailing list.  As a result 
of this experience we were forced to downgrade back to Samba 3.5 for 
stability.  We performed initial tests on Samba 4 and found it 
adequate.  But, once we brought it up for production, we noticed a deal 
breaking issue.  When browsing a share, 90% of the time, the Samba 
process will get stuck in some kind of loop and start using 100% of the 
CPU it is assigned to.  After scouring through the mailing list archives 
and googling it, we found two bug reports (10158 and 10358) of similar 
issues.  Hoping to correct this problem we applied the provided 
patches.  Unfortunately, neither solved our problem.  Samba processes 
were still getting stuck at 100% cpu usage.  This problem would affect 
multiple Samba processes, sparked by users browsing Samba shares.  After 
two processes reached 100% cpu usage, the entire Samba group of 
processes would freeze, making all shares unresponsive and inaccessible, 
forcing us to restart Samba.  We started monitoring samba processes 
through top and killed any that started to reach 100% cpu usage.  This 
practice, as you can imagine, made for a bad user experience.  The 
smb4.conf file we used is as follows....


# Global parameters
[global]
         workgroup = STANCORPBSD
         realm = ESRECO.NET
         netbios name = FRODO
         server role = active directory domain controller
         dns forwarder = 107.1.251.82
         server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, 
winbind, ntp_signd, kcc, dnsupdate, dns, smb
         dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, 
netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser, 
eventlog6, backupkey, dnsserver, winreg, srvsvc
         idmap_ldb:use rfc2307 = yes

         logon drive = p:
         logon script = logon.bat
         domain logons = Yes
         preferred master = Yes
         domain master = Yes
         nsupdate command = /usr/local/bin/samba-nsupdate -g
         printing = bsd

[netlogon]
         path = /var/db/samba4/sysvol/esreco.net/scripts
         read only = No
         log level = 3

[sysvol]
         path = /var/db/samba4/sysvol
         read only = No

[home]
         path = /a/standard/home
         read only = No

[profiles]
         path = /a/standard/profiles
         read only = No
         csc policy = documents

[data]
         comment = Data Store
         path = /a/standard/data
         write list = @staff, @wheel, @ar
         read only = No
         create mask = 0777
         directory mask = 0777


....

Needless to say, we will be conducting the acid test on any future Samba 
4 deployments before they're put into production.  We were hoping that 
minimal initial testing would be adequate because the team that develops 
Samba is widely known for it's quality releases, and the Samba 3.x 
series has been nothing but rock solid stable for us, but as you can 
see, we were burned by that assumption.  As for now, the software is, as 
the install process indicates, "..still experimental.." and we will 
remain with Samba 3.x until future Samba 4 releases are available, 
hopefully correcting the nasty CPU usage bug (most likely some kind of 
loop) we ran into.

However, we are not discounting the possibility that there may have been 
a configuration problem.  We suspected a problem with using the ntvfs 
file system as opposed to the s3fs because we were coming from s3fs.  We 
were forced to use ntvfs because we primarily use ZFS as the underlying 
file system on FreeBSD.  We also used the built-in DNS with a a 
forwarding IP for our main DNS server.

System/Software information:

FreeBSD 9.2 release
Samba 4.1.4

The Samba software was installed through the FreeBSD ports system.

Any suggestions or ideas of why Samba 4.1.4 failed us are welcome. We of 
course would like to provide any information that will help track down 
and crush this bug, which does make the software unusable on FreeBSD, IMHO.


Regards,

Eric