Samba server process model

Revision as of 23:00, 28 January 2019 by Timbeale (talk | contribs)

The samba process has different models for how it manages client connections (e.g. RPC, LDAP connections, etc). The process model is specified by the --model command line argument when Samba is first started. The available models are:

  • standard: The default. Each Samba service (LDAP, RPC, etc) runs in a separate process. For services that support it (LDAP and NETLOGON), a separate process is forked for every accepted connection from a client.
  • prefork: Each Samba service (LDAP, RPC, etc) runs in a separate process. A fixed number of worker processes are started for those services that support it (currently LDAP, NETLOGON, and KDC). Instead of forking a separate process for each client connection, the connections are shared amongst the existing worker processes. Requests for services not supporting prefork are handled by a single process for that service.
  • single: Everything gets done in a single process. This is recommended only for testing and debugging, not for production networks.

Note that these options only control the behaviour of the samba process, not the smbd process.

You can see what samba processes are running by using the samba-tool processes command on your DC.

Prefork model

The prefork model is recommended for Samba setups where there are either a large number of transitive client connections, or the client connections remain open for long periods of time. Otherwise, with the standard process model, Samba can end up forking large numbers of processes to manage these connections.

You may want some thought/investigation into the number of prefork worker processes that will best suit your network. This is specified by the prefork children smb.conf option.

Prefork support for LDAP connections was added to Samba v4.9. Prefork support for NETLOGON and KDC was added to v4.10.

Prefork restart

If a prefork worker thread were to crash for some reason, it will be restarted. If it were a persistent problem, then respawning the worker process could consume a lot of CPU resources. To mitigate this situation, there will be a backoff period before the worker thread is respawned. During this time, the client connections will be processed by the remaining prefork worker processes (providing you're not using prefork children = 1). To control this respawn behaviour, use the prefork backoff increment and prefork maximum backoff settings in the smb.conf.