Fletcher Cocquyt <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
