Hi Lisa,
You did a good job of summarizing the situation. Let me try and fill
in a few details, hopefully not making it too confusing.
There are two main kinds of locks that Qpopper uses (with some
potential variances within them):
To make sure that only one process at a time is modifying the mail
spool, a maillock is held only during the start and end of the
session. Qpopper obtains a maillock on the spool, copies the spool
to the temp drop, zeroes the spool, and releases the maillock. Local
delivery agents delay mail delivery while the maillock is held.
At the end of the session, Qpopper again obtains a maillock on the
spool, appends any mail that arrived during the session to the temp
drop, copies the temp drop to the spool, removes or zeroes the temp
drop, and releases the maillock.
Maillocks need to be interoperable between any program that accesses
the spool. It wouldn't be good if Qpopper used one method while the
local delivery agent used another. Not to mention all the other
programs that could be used to modify the spool. Qpopper by default
uses the ".lock" technique, which is compatible with maillock(3) as
implemented on many platforms.
While the session is in use, Qpopper holds an advisory lock on the
temp drop. The advisory lock is only needed to prevent multiple POP
sessions from altering the temp drop.
Maillocks typically are a file which is the name of the spool with
".lock" appended. The modtime of the file must be less than five
minutes, or the lock is considered stale and is discarded. There are
other possible lock mechanisms, and variations in how the lock is
created, that can be selected using obscure options in Qpopper.
Advisory locks use flock(2).
There are differences that depend on server mode and various obscure
options. Server mode is the main and most used option that affects
locking.
The key is that if the spool is maillocked, Qpopper waits a
reasonable amount of time. So under normal circumstances, if a user
checks mail at the exact moment that the local delivery agent (LDA)
is appending new mail, Qpopper waits until the LDA is done, and then
the POP sessions runs normally.
However, if Qpopper is unable to obtain the advisory lock on the temp
drop, it assumes the user has another session active and issues an
[IN-USE] error.
If the user gets an [IN-USE] error, the first thing to check is if
there is an active popper process for that user and if the user is
connected to it. If not, a ktrace(1), truss(1), or similar should be
done to see what it is doing and why it has not gone away. If the
user disconnects, Qpopper should get a signal and will then clean up
and terminate. You can allow the user access by killing the popper
process if it is running and removing the temp drop. Prepending the
temp drop to the spool first should prevent loss of mail. You
shouldn't ever have to do either, and there is always some risk of
corruption or loss if you do either.
In server mode the spool isn't copied to the temp drop at the start
of the session, but is still created and locked. At the end of the
session, any undeleted mail is copied to the temp drop.
The "Performance" section in the Administrator's Guide (the GUIDE.pdf
file) has more information on server mode.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
DEFINITION: Computer -- A device designed to speed and automate errors.
