(After adding 'dsdb:schema update allowed = yes' to the conf file,) In a one-DC domain running Samba (and a one-DC forest FWIW,) when making many schema changes from a Windows client, Samba gets overloaded and stops responding to all requests (LDAP, authentication, further schema changes, etc.), causing most other client operations to time out, thinking the DC has gone off-line. This lasts for at least one minute but I've seen it be as high as 15, depending on the number of schema change requests that have queued up. My environment: - Debian Jessie (currently 'testing') - 2x Intel Pentium Xeon 2.8GHz (single-core with HT, 32-bit w/ PAE) - 3.14.12-686-pae i686 kernel - Samba 4.1.9 from Debian repos To reproduce: 1) Bring up a Samba server (with default schema) with all domain master roles 2) Download and extract an Exchange installer (to get a bunch of LDF files to apply.) http://go.microsoft.com/fwlink/p/?LinkId=398005 3) On a Windows machine with RSAT tools installed, change to the setup\data\ directory of the extracted package (where the LDFs are) and issue the following command: for /l %x in (1,1,99) do ldifde -i -f postwindows2003_schema%x.ldf -c "<SchemaContainerDN>" "CN=Schema,CN=Configuration,DC=foo,DC=example,DC=com" (You can also add a '&& pause' at the end if you want to manually step each file.) 4) Watch top on the Samba machine and notice that a 'samba' process will soon run at 100% CPU (pinning one core) when on the Windows machine the dots next to "Loading schema changes" stop printing. Authentication efforts from other machines will fail or be severely delayed while this is happening. Note that if a given LDF file has already been applied, the ldfde command for that file completes successfully in a normal amount of time with no adverse effects. (I will try to get a back-trace but this is a production system so I can only do this after-hours.)
I strongly suspect this is fixed in Samba 4.5rc1, where we now handle schema updates better. If not please re-open after running the test under 'perf record' and get me a flame graph per http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html so we can can isolate the issue.