webauthldap(SUNetID): cannot get ticket: Too many open files (24)

[Russ Allbery]

Fletcher Cocquyt <fcocquyt at stanford.edu> writes:

> Hi, I am following the code now on this one - after posting to the
> webauth list a couple weeks ago we are still experiencing several
> hundred of these errors per day - we have maxed out our file descriptors
> hard and soft limits at 64k and verified with running plimit.
>
> webauthldap(SUNetID): cannot get ticket: Too many open files (24)
>
> Env: Solaris 9, apache 2.0.52, webauth 3.5.4, MIT kerberos krb5-1.4.1
>
> Our apache threads are now approaching 250-300 open files (as reported
> by lsof).

What does lsof say that these open files are?  Are they all legitimate
open files that you expect?

> Hypothesis: This version of webauth & kerberos is somehow not using the
> 64k file descriptor limit, but is using a 256 file limit and throwing
> the error on the ticket operations when the apache thread has more than
> 256 files open.

Oh, good call.  I should have thought of that.

With Solaris 9, this can happen with things that use stdio.  I don't know
if Kerberos 1.4.1 uses stdio to open its ticket cache files.  As near as I
can tell, current development versions of Kerberos don't, and I don't see
any sign of it in 1.4.4, but I may be missing something.

> there are other threads related to the use of char vs int resulting in
> return value overflow...

Solaris 9 uses a char to store the file descriptor number in the FILE
struct used in stdio and hence has an artificial limit on the number of
open file descriptors that can be addressed by stdio.

If this is the case and Kerberos is using stdio, then there aren't a lot
of good solutions that I'm aware of.  64-bit builds will also not have
this problem.  It might be fixed in Solaris 10, but part of the problem is
that it's hard to fix without changing the binary ABI.  I think there are
build-time hacks you can use to change the FILE struct, but you have to
rebuild everything with those hacks and I don't remember the details.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>