[tpop3d-discuss] The way locking in /var/mail works...

[Chris Lightfoot]

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)