Re: Puzzling pop lock files

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.