Apply patch for socken listen backlog (FreeBSD)

Osipov, Michael michael.osipov at
Sat Jan 12 21:21:40 UTC 2019

Am 2019-01-12 um 11:33 schrieb Volker Lendecke via samba-technical:
> On Fri, Jan 11, 2019 at 01:29:54PM -0500, Andrew Walker via samba-technical wrote:
>> This is perhaps a more targeted fix for FreeBSD. If a 'backlog' value of
>> less than zero is specified, then the backlog is silently forced to
>> kern.ipc.soacceptqueue on FreeBSD. Do note that we have observed
>> significant problems in large environments on FreeBSD that required this
>> change, and so there is definitely merit in addressing it in some way.
> This change looks of course ok. I'm not sure I like the #ifdef
> FREEBSD, but if this is really something FreeBSD specific, then it
> might be the right way to go.
> I'd like to understand the patch and its necessity a bit better. The
> listen backlog copes with the process doing the accept() being too
> slow, right? Where exactly do you see the problems, where is smbd or
> winbind too slow? The smbd process doing the accept should not do much
> work before doing the fork, returning to polling the acceptor socket.
> What is the scenario that you're fixing with this? If the parent smbd
> does significant work between the accept calls, I think we also need
> to fix that. Likewise for winbind.
> What is it that makes this a FreeBSD specific problem?

This is netstat in idle:
> # netstat -Lan
> Current listen queue sizes (qlen/incqlen/maxqlen)
> Proto Listen                           Local Address
> tcp4  0/0/128                
> tcp4  0/0/50                 
> tcp4  0/0/50                 
> tcp4  0/0/128                          *.5555
> tcp4  0/0/128                          *.21
> tcp4  0/0/10                 
> tcp4  0/0/128                          *.22
> tcp4  0/0/128                          *.10050
> tcp4  0/0/128                          *.603
> tcp4  0/0/128                          *.748
> tcp4  0/0/128                          *.2049
> tcp4  0/0/128                          *.1009
> tcp4  0/0/128                          *.600
> tcp4  0/0/128                          *.111
> unix  0/0/5                            /var/db/samba4/winbindd_privileged/pipe
> unix  0/0/5                            /var/run/samba4/winbindd/pipe
> unix  0/0/5                            /var/run/samba4/nmbd/unexpected
> unix  0/0/30                           /var/run/hald/dbus-EVU64eQXQL
> unix  0/0/30                           /var/run/hald/dbus-1zay8aU2yN
> unix  0/0/128                          /var/run/rpcbind.sock
> unix  0/0/4                            /var/run/devd.pipe
> unix  0/0/30                           /var/run/dbus/system_bus_socket
> unix  0/0/4                            /var/run/devd.seqpacket.pipe

We had lockups with an overfull queue which is hard to monitor exactly 
at the time of the lockup because the entire system is unresponsive. I 
am not even 100% sure if that is the cause, but it could be.
As you can see, everyone else is using -1, but Samba is not.

I don't consider this to be a Freebsd specific problem because listen(2) 
is a POSIX function. I expect the admin having the possibility to modify 
the backlog according to the server load. -1 looks like a good defaut 
value which is determined by the OS. For those which are set to 5 for 
local/IPC communication should be controllable too.

I am not happy with the provided patch because it turns literals into 
defines which cannot really be changed at runtime.

options in the smb.conf and everyone will be happy.


More information about the samba-technical mailing list