On Thu, May 29, 2003 at 07:27:36AM +0200, Martin Schmitt wrote: > > However, since I've started using TMDA, I found that my mailbox remains > locked forever in some situations. There's a /var/mail/martin.lock that > just won't go away. I haven't yet been able to willfully reproduce such a > status, but it happens fairly often, like once a week.
You're certain that this lock was created by tpop3d? What's in the lockfile? You should be able to compare the PID to PIDs which tpop3d lists in syslog, to confirm which program is responsible. > I have tried to manually authenticate against TPOP3D and saw that TPOP3D > locks the mailbox immediately after USER/PASS were submitted successfully. > I don't know enough about the implementation of POP3 servers to judge if > that's the right time for locking or not. > > Now, my question is: Who is behaving in a "wrong" kind of way here? Does > TPOP3D lock the mailbox too early, or does one of tmda-cgi and tmda-ofmipd > not terminate their POP3-session properly? Obviously POP3 implementors have a choice of how to do locking. In the case of tpop3d I chose the simplest (and fastest) option, which is to lock the mailbox from the time that the user logs in to the time that the connection is broken (whether that's after logout or not). > If I don't find a direct solution, I can build some kludge to work around > it as the TMDA components support other means of authentication. However, > I'd like to handle it in a "clean" kind of way. If it's tpop3d's lock file, that's a bug and I'd like to know more. But as a workaround, you can recompile tpop3d to use fcntl locks only; fcntl locks cannot become `stale'. However, if you do this, you must satisfy yourself that other MDAs and MUAs on the system also use this type of lock. -- ``Decommissioning is the perpetual rock upon which we have come adrift'' (Peter Mandelson) _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
