fd (file descriptor) leak in replay cache

[Parity error]

Rob, i have tried with the latest 1.14.5 and still face the same issue.
Basically the number of open fds to files like /var/tmp/krb5_RCxxxxxx
just keeps on increasing, almost monotonically. There are open fds to
/var/tmp/host_1000, but these increase and then decrease and stay
within 20 or 30 descriptors (to the same file). However the fds to
/var/tmp/krb5_RCxxxxxx has just kept on increasing to thousands..

It would help a lot for my debugging if you could tell me how these
krb5_RCxxxxxx files are used. There is a rename and dup also going on.
I have made sure that the security context is deleted with a call to
gss_delete_sec_context(). However the acceptor_cred_handle is obtained
once when the process starts and is given to each invocation of
gss_accept_sec_context() and only freed when the process terminates.

On 4/20/17, Robbie Harwood <rharwood at redhat.com> wrote:
> Parity error <bootup32 at gmail.com> writes:
>
>> We have been using the kerberos 1.10.3 library and we find that
>> occasionally a lot of the following files are kept open by the library
>> and they fill up the fd limit of the process,
>
> Hopefully someone else has a more detailed answer for you, but there
> have been 82 commits since then which are leak fixes, some of which may
> relate to the problem.  So: "probably".
>
> Unfortunately, krb5-10 is from early 2012.  MIT upstream focuses most
> support efforts around 1.15-series (current release) and 1.14-series
> (maintenance release).
>
> If you can reproduce it on another system, perhaps try with a newer krb5
> and see?  (Based on the version, you're using Centos6; Centos7 has
> krb5-1.14.1 at the time of writing.)
>
> --Robbie
>