Winbindd limited by select

Ken Cross kcross at
Thu Feb 13 02:19:44 GMT 2003

There is pretty much a one-to-one correspondence between the number of
smbd processes open (i.e. connected users) and winbindd file descriptors
(per fstat).

I think forking would be counter-productive since winbindd caches so
much stuff.  A lot of it's in tdb files, though, so...

Frankly, I'm not sure what the smbd's are doing with winbindd after
authentication.  There's another discussion looming about closing idle
connections to winbindd.


Ken Cross

Network Storage Solutions
Phone 865.675.4070 ext 31
kcross at 

-----Original Message-----
From: Esh, Andrew [mailto:Andrew_Esh at] 
Sent: Wednesday, February 12, 2003 7:34 PM
To: 'Martin Pool'; Michael Steffens
Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL'
Subject: RE: Winbindd limited by select

Better yet: Have winbindd fork the same way smbd does, on a per-client

Someone should probably figure out what quality of the example network
caused winbindd to consume so many sockets. Are there really that many
requests being queued up at once? Shifting to a forking model would
simply consume the same number and more processes. They are limited too.

We also need to be sure all the requests are making progress. If one
gets hung, the client program would probably repeat the request,
expending another instance of everything. Are there really 2048 users
actively trying to make winbindd requests at the same time?

Perhaps this is the result of a very network-common failed NIS request,
which falls through the passwd list in /etc/nsswitch.conf, and winds up
asking winbindd about the same non-existent user. What is the content of
the requests, and is there some way to fix the system so the users don't
cause them to be issued at such a high rate? Should they even be
forwarded to winbindd at all?

Maybe winbindd is piling up requests as it searches for a domain
controller at the head of its "password server" list which is no longer
working, or is no longer in DNS. Reorder that list, and winbindd might
begin to process requests fast enough to stay ahead of the influx rate.

> -----Original Message-----
> From: Martin Pool [mailto:mbp at]
> Sent: Wednesday, February 12, 2003 5:56 PM
> To: Michael Steffens
> Cc: Ken Cross; 'Multiple recipients of list SAMBA-TECHNICAL'
> Subject: Re: Winbindd limited by select
> On 12 Feb 2003, Michael Steffens <michael.steffens at> wrote:
> > It's 60 by default after installation, but is tunable (with reboot).
> Maybe hp should sell per-fd licences :-/
> > The solution (and this should also work on other platforms) was to 
> > have winbindd housekeep its client connections by shutting down idle

> > connections, and have clients reconnect when required:
> > 
> >   
> The threshold was chosen to be 100 active connections, which keeps 
> winbindd well below 300 FDs. Below 140, actually, including network 
> sockets and open database and log files.

I wonder how well it would work to have one winbindd process per n
clients, in addition to shutting down idle clients...


More information about the samba-technical mailing list