Winbindd limited by select

Ken Cross kcross at
Sat Feb 15 12:49:00 GMT 2003


It's both.  I hadn't mentioned it, but I also had to add this to

  rlim.rlim_cur = 1500;              // Files
  rlim.rlim_max = rlim.rlim_cur;
  stat = setrlimit( RLIMIT_NOFILE, &rlim );
  if( stat != 0 ) DEBUG(0, ("Failed to set file limits: %s",
strerror(errno) ) );

The default file limit in NetBSD is 128, so that killed winbindd sooner
than the fd set.

However, in NetBSD, there's no real limit to the size of the fd set
passed in the select function.  If it's larger than the size defined in
the kernel (256), the kernel just malloc's more to accommodate it.  So
changing FD_SETSIZE in the calling program was sufficient to fix the


Ken Cross

Network Storage Solutions
Phone 865.675.4070 ext 31
kcross at 

-----Original Message-----
From: Michael Steffens [mailto:michael.steffens at] 
Sent: Saturday, February 15, 2003 7:39 AM
To: David Collier-Brown -- Customer Engineering
Cc: jra at; Ken Cross; 'Multiple recipients of list
Subject: Re: Winbindd limited by select

David Collier-Brown -- Customer Engineering wrote:
> Ken Cross wrote:
>>> #define FD_SETSIZE 2048  /* Max # of winbindd connections */
>>>must occur before the first invocation of <sys/types>.
>>>This could be a build option, but it might be much simpler to 
>>>hard-code it in local.h, which is what I did to fix it.
>>>Can somebody check the implications of this on Solaris, HPUX, etc.?
> 	On Solaris, compiled as a 32-bit app, the limit
> 	applies.  Compiled as a 64-bit app, you can have 
> 	as many FDs as you want.
> 	However, there is currently no good reason to build
> 	Samba as a 64-bit app: it doesn't need a bigger
> 	address space.

I'm wondering, basically concerning all platforms, whether this is about
the size of fd_set, or about the number of FDs the kernel will actually
assign to a process.

If the latter one is not limited, wouldn't a single excessive FD
consumer impact other processes?


More information about the samba-technical mailing list