Apply patch for socken listen backlog (FreeBSD)

Osipov, Michael michael.osipov at siemens.com
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                          127.0.0.1.6010
> tcp4  0/0/50                           147.54.64.14.139
> tcp4  0/0/50                           147.54.64.14.445
> tcp4  0/0/128                          *.5555
> tcp4  0/0/128                          *.21
> tcp4  0/0/10                           127.0.0.1.25
> 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.

So I'd replace SMBD_LISTEN_BACKLOG and DEFAULT_LISTEN_BACKLOG with two 
options in the smb.conf and everyone will be happy.

Michael



More information about the samba-technical mailing list