[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Exim + POP3 + quota problems


If you are able to re compile Qpopper, you can change the location of the <user>.lock file as a compile option, just put it some where there is no quota checking. You will also need to adjust the configuration of your MDA to watch for lock files in that new location. I ran into this same problem a couple of years ago (when I worked at Qualcomm :). I was also constantly having to repair the users mbox files because of corruptions in the headers that would cause Qpopper to die.

There are a lot of compile time options that you can adjust and if you just have to keep using it, do re-compile with the "server mode" enabled. I forget the exact name of that option but it keeps the users spool file copies to only 1 per session. This change alone brought the load on our mail servers down to less than 1.0.

I would recommend going with something like qmail (I like it more than anything else I have used) or any other pop server that supports Maildir. The only mail servers I didn't have to work on (fixing) have been those using Maildir.

Hope this helps,

At 10:11 PM 03/17/2002 -0600, Rich Puhek wrote:

Marcin Owsiany wrote:
> Hi!
> Here's my setup:
>  - a potato box (sounds cool, doesn't it? :-)
>  - exim delivers mail to /var/mail/<user>
>  - qpopper is my POP3 server
>  - there is a user quota for /var partition
>  - /var/spool/pop is a symlink to /usr/local/pop
>  - there is no user quota for /usr/local partition
>  - all users use POP3 to fetch their mail
>  - also, a few users do read mail via local MUAs,
>    so disabling locking in qpopper is not possible
> The problem is that from time to time the following thing
> happens:
>  - the size of a user's mailbox in blocks becomes equal to the user's
>    quota on /var
>  - because the user may not use any more blocks on that partition,
>    qpopper is unable to create a lockfile (/var/mail/<user>.lock)
>    and exits with
>    -ERR maillock: cannot lock '/var/mail/foo': 1
>  - because of that the user is unable to fetch her mail
> How do you guys cope with that problem? The only solution I could come
> up with is switching to Maildir delivery, but might be painful...
> Maybe there's some solution I've overlooked?

Argh... yes, use Maildir, have procmail deliver locally, drop qpopper
for courierpop, qmail's pop server, or any of the other Mailbox-aware
servers. You'll have a lot less trouble in the long run IMHO. The
changeover isn't really that painful either.

Been a while since I dealt with qpopper, but wasn't the lock actually
/var/spool/pop/<user>.pop (the temporary copy of the user's mailbox)?

If that's correct, mount /var/spool on a different partition from
/var/mail, and only enable quotas on /var/mail. If you've got any load
on the server, you'll want /var/spool, /var/log, and /var/mail on
seperate drives for performance anyhow.



Rich Puhek
ETN Systems Inc.

To UNSUBSCRIBE, email to debian-isp-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Loren Jordan

Network Security Admin
National White Collar Crime Center
Internet Fraud Complaint Center
Phone (304)363-4312 Ext 2011


Reply to: