I am successfully (and happily) using courier-imap-4.0.6 (I use the Gentoo GNU/Linux distribution).
I had trouble using a courier-imapd account on my computer after it underwent a reboot. Whenever the client tried accessing the trash folder, courier-imap would sit waiting for a lock to be broken. When my computer loaded its daemons after the reboot, the dkim-filter milter claimed the PID of a long-dead courier-imapd process. The process had been accessing the .Trash/tmp folder of this account right as my computer died, leaving the stale lock. Is it possible for a future version of courier-imapd to correct such a problem itself by recognizing that /proc/$PID/exe != /proc/self/exe? I know that such a thing should not be checked everytime a lock is found because locking must be efficient. But if a lock can not be claimed for half a minute or so, I think the process would be benefited by examining the validity of the lock. I did not see this feature discussed in the ChangeLog ( http://www.courier-mta.org/imap/changelog.html ) for a newer version of courier-imap. Also, is this the place to report bugs? Below is an edited shell session of me finding and removing the stale lock: margbr...@ohnopublishing ~/.maildir/.Trash/tmp $ ls -lha ... -rw-r--r-- 1 margbrink margbrink 8 Jul 21 21:00 1248224418.M734712P16152.ohnopublishing.net -rw-r--r-- 1 margbrink margbrink 23 Jul 18 21:19 courier.lock $ less courier.lock 7892:ohnopublishing.net $ ps -Aef |grep 7892 milter 7892 7891 0 Jul19 ? 00:00:03 /usr/sbin/dkim-filter -x /etc/mail/dkim-filter/dkim-filter.conf -P /var/run/dkim-filter/dkim-filter.pid 1014 16669 16594 0 21:18 pts/6 00:00:00 grep --colour=auto 7892 $ rm courier.lock -- binki ------------------------------------------------------------------------------ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
