I'd be curious to find out what conditions cause this as well. I have not had a single orphaned /tmp/krb5 ticket leftover since I've patched 2004a with the 2004b.DEV code.
I can't imagine why one would want to kill the process using any kind of signals on a regular basis, but like you said that this was just yet another way to create orphaned kerberos tickets under /tmp. We're using Redhat Enterprise 3, which ships with 2002d (real old). So I installed the 2002d SRPM redhat provides, and rebuilt the binary RPM using 2004a with all the appropriate patches along the way. If you're using RH I'd be happy to provide you with my binary RPM to try out. I've yet to rebuild the SRPM because of all the manual patching I had to do. -----Original Message----- From: David Lee [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 5:05 AM To: Mark Crispin Cc: [EMAIL PROTECTED]; Jason Sauve Subject: RE: Possible IMAP Bug Causes IMAP with PAM_KRB5 to rapidly deplete INODEs and DISK space On Tue, 14 Sep 2004, Jason Sauve wrote: > Your src/osdep/unix/env_unix.c patch in yesterday's DEV build > absolutely fixed the problem with the logout hook not being called. > [...] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Mark Crispin > Sent: Monday, September 13, 2004 5:34 PM > To: Jason Sauve > Cc: [EMAIL PROTECTED] > Subject: RE: Possible IMAP Bug Causes IMAP with PAM_KRB5 to rapidly > deplete INODEs and DISK space > > Thank you for your investigation work; and in particular for your > information that the logout hook was not being called. > > I believe that this problem is remedied in today's > ftp://ftp.cac.washington.edu/mail/imap-2004b.DEV.tar.Z I think I can further confirm that this fix is largely (order 90%) effective. History: A couple of years ago, we had massive quantities of /tmp/krb5* files accumulating. At the time, the code in "ckp_pam.c" had an "#if 0" disabling code that would unlink these files at their creation; I enabled this and it solved our problem. (See also my email of 19 April 2004.) Last week, I had installed vanilla imap-2004a: the "/tmp/krb5*" problem reappeared with a vengeance, and we quickly had 20,000 (and rising) such files. I then extracted your "src/osdep/unix/env_unix.c" change from "imap-2004b.DEV" and applied that to our "imap-2004a". Things are now vastly better. However there is still a smaller-scale lurking problem causing some /tmp/krb5* files to remain. I don't know how the users precipate this condition from email sessions, but I can reproduce something similar (same?) "under the bonnet" within the server: o A clean session (imap login/logout) is fine (the /tmp/krb5* file is cleanly removed at session end). o Sending a HUP to imapd (dies) is also fine (file cleanly removed). o Sending a TERM or INT to imapd (dies) leaves the file hanging around. So that "imap-2004b.DEV" change has made a huge improvement, for which many thanks. But there remain some circumstances under which /tmp/krb5* files can be left around (we are seeing a few thousand per day, so I still need my tmp-flushing cron job). Hope that helps. -- : David Lee I.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/ South Road : : Durham : : Phone: +44 191 334 2752 U.K. :
