Sam Varshavchik wrote: > There's a two minute timeout on this lock. If this lock exists, after > two minutes it gets removed by the waiting imap process. Are you sure? The lockfile was dated July 18 and I ran the ls -lha command that examined the .Trash/tmp folder on July 21 (see shell output of my initial post). In my case, the lockfile sat around for a day or so. > There are two reasons I could think of why this file would not get > cleared after two minutes. One would be the mailboxes on an NFS mount, > and there's a major clock skew on the NFS server; easy to fix -- fix > the clock and use ntp. This is a local filesystem. For some reason, the client of courier-imapd must have caused the lock to be held long enough that it happened to get committed to the on-disk FS at the moment my machine froze. > The other reason is that this code gets used only on platforms with > FAM or gamin libraries. FAM/gamin can occasionally be miscompiled or > broken, that's one thing to look into. I have compiled (and use) courier-imapd-4.0.6 with fam support provided by gamin-0.1.10. I'm not sure what could go wrong with gamin/fam, as the lockfile wouldn't change such that it would trigger fam unless if it actually was unlinked. As I said, my lockfile sat around for a day or so because it held a valid PID (I'd assume).
I see that liblock/mail.c:ll_mail_lock() only checks kill(pid, 0), it'd be nice if it could somehow verify that the process it's checking is a courier-imap process. Maybe this is impossible :-)... but it'd be nice. -- binki ------------------------------------------------------------------------------ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
