stdio in smbd

[Andy Polyakov]

A year has passed so here it goes again...

> > The stdio library on Sun architecture is limited to file descriptors less than 256 and this
> > limitation is being encountered with some regularity in our smbd processes.
> [...]
> 
>  These problems don't happen unless your clients use a lot
> > of open files but a group of our users here seem to have 200-400 open files almost all the time.
> >
> > Is anyone working to convert the stdio calls to other functions using file descriptors?
> 
>         Not that I know of: The lower
> limit is 0x100 (256), the upper is  1024 (see sysdef on
> you machine; my Slolaris 8 (:-)) system says
> *
> * Process Resource Limit Tunables (Current:Maximum)
> *
>           Infinity:Infinity             cpu time
>           Infinity:Infinity             file size
>           Infinity:Infinity             heap size
> 0x0000000000800000:Infinity             stack size
>           Infinity:Infinity             core file size
> 0x0000000000000100:0x0000000000000400   file descriptors
>           Infinity:Infinity             mapped memory
> 
> The per-process limit can be set via the ulimit -n command in ksh,
> if I remember correctly.
> 
> The limit can be set to 1024 for any 32-bit Solaris
> process, and to huge values on 64-bot OSs for 64-bit
> smbds by adding the follwoing to /etc/system anbd
> then setting ulimit:
> 
> set rlim_fd_max = 4096
> set rlim_fd_cur = 4096

These are false statements. The limit can be set to whatever value for
whatever process *without* modifying /etc/system or rebooting. What is
true is that *sh won't set it to a value larger than rlim_fd_max kernel
variable, but it doesn't meand that smds can't. And you know what? 2>=2
*does*!!! What is true is that 32-bit processes using select(3C) go
berserk if the limit is set over 1024. What is also true is that 32-bit
processes using stdio(3S) go berserk if the limit is set over 256. Now
given that smbd successfully sets the limit to the default "max open
files" of 10000 (once again! it does!!! check with 'pfiles <smbd's pid>'
for yourself!) latter two conditions are very likely to be satisfied
(because by default smbd is compiled as 32-bit!) and it simply *breaks*
at some point. For further discussions and workarounds see "Proposed
patch for Samba-2.0.7 to allow Solaris open more than 1014 (or
rlim_fd_max) files" *thread* at
http://lists.samba.org/pipermail/samba-technical/2001-January/thread.html#27212.
I can only add that following is also essential:

*** lib/util.c.orig     Sat Oct 13 23:09:26 2001
--- lib/util.c  Thu Dec  6 01:47:44 2001
***************
*** 1535,1540 ****
--- 1535,1543 ----
        if (rlp.rlim_max != RLIM_INFINITY) {
                int orig_max = rlp.rlim_max;
  
+               if (requested_max > FD_SETSIZE)
+                       requested_max = FD_SETSIZE;
+ 
                if ( rlp.rlim_max < requested_max )
                        rlp.rlim_max = requested_max;
  
A.