I actually had a similar but more sinister problem. I have RH Linux
6.2, raid-tools 0.9 (and two 18 GB disks striped for a single md
volume) and quota in combination with qpopper 3.1.
We didn't turn on quota in the beginning but then we started it
using a 10 MB limit. What happened was that qpopper would generate
a lock file and quota would complain for users with oversize files
but the lock went ahead anyway and copy the mailbox to a temp file
(.user.pop). If the user changed something (deleted a message etc.)
then qpopper would complain about not being able to copy the temp
file to the mailbox file and quit. However, sometimes the user would
log in the next time he would have an empty mailbox and a nonexistent
temp file.
We never figured what caused the mailbox file to become empty, but
sometimes there would be an incoming message between pop accesses
but not always...
We finally turned off quota and the problem went away (newest
raid-tools amd quota packages) and the concensus was that there
must have been some incompatibility between quota and raid-tools...
I am curious if anyone has met similar problems or has any insight?
We would like to implement quota again but not at the expense of
lost mail...
Thanks,
-GSH
Qpopper Support wrote:
>
> At 1:02 PM -0600 10/30/00, Joy wrote:
>
> > I am using a linux box using red hat 5.2, 2.2.5 kernel, qpopper 3.1
> > server mode, auto delete, and bulldb, and have a question about pop lock
> > files. How long does a .user.pop file stick around after a connection
> > has been broken? Is there a setting to change the time that it sticks
> > around? I have noticed that a customer was repeatedly trying to get his
> > mail (with the longest pop break of 13 minutes) which had a pop lock
> > file. After a 14 min break from checking his mail the lock went away.
>
> The .user.lock file should go away when the popper process for that
> user exits. If the user's spool is especially large, this may take a
> few minutes. If the popper process dies before it can finish
> cleaning up, the .user.lock file will stay around. The next popper
> process for that user will usurp the lock if it is older than 5 or 15
> minutes. (While the lock is in use Qpopper refreshes it every minute
> or so, to ensure that it doesn't become stale.)
>
> The .user.pop file should also be removed when the popper process
> cleans up and terminates. However, if it stays around, the next
> popper process will simply use it (unless the first popper process is
> still active).
>
> If you can reproduce a situation where the user disconnects, the
> popper process for that user dies, and the .user.lock or .user.pop
> files stays around, please let me know.
