[Dovecot] 1.2.4 Maildir Quota Issues
Has anybody noticed this behavior when using maildir quota with Version 1.2.4:
1.2.4: /etc/dovecot/dovecot.conf
OS: Linux 2.6.26-2-686-bigmem i686 Debian 5.0.3 xfs
My default configurations quota configurations: plugin: quota: maildir:User quota quota_rule: *:storage=2G
Customized Use Configurations at the Mysql level:
user_query = SELECT 5000 AS uid,5000 AS gid,'/vmail/%d/%n' as home,
concat('*:storage= ', virtual_users.quota_kb) AS
quota_rule
from virtual_users LEFT JOIN virtual_domains ON
virtual_users.domain_id=virtual_domains.id
where virtual_users.user='%n' and virtual_domains.name='%d'
When I change quota at the SQL level (per user), that quota becomes active once Dovecot is restarted. Until then it keeps the previous quota assigned. I do not remember seeing this behavior in previous versions --quota was active after sql changes.
M.A.
On Sat, 2009-09-12 at 10:06 -0400, Mario Antonio wrote:
Has anybody noticed this behavior when using maildir quota with Version 1.2.4:
When I change quota at the SQL level (per user), that quota becomes active once Dovecot is restarted. Until then it keeps the previous quota assigned. I do not remember seeing this behavior in previous versions --quota was active after sql changes.
This likely has something to do with the auth_cache value.
Try on a fresh user, change it, try 2 minutes before auth_cache would expire, and then again 2 minutes after.
-- Kind Regards, Noel Butler L.C.P #251002 (http://counter.li.org)
This Email, including any attachments, may contain legally privileged information, therefor remains strictly confidential and is protected under Australian Laws and international treaties. You may not disseminate or reveal any part to anyone without the authors express written authority to do so. If you are not the intended recipient, please notify the sender and delete all relevance of this message including attachments immediately. Confidentiality and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF or ODF documents are accepted, do not send Microsoft proprietary formatted documents - see http://www.gnu.org/philosophy/no-word-attachments.html
On Sun, 2009-09-13 at 07:25 +1000, Noel Butler wrote:
On Sat, 2009-09-12 at 10:06 -0400, Mario Antonio wrote:
Has anybody noticed this behavior when using maildir quota with Version 1.2.4:
When I change quota at the SQL level (per user), that quota becomes active once Dovecot is restarted. Until then it keeps the previous quota assigned. I do not remember seeing this behavior in previous versions --quota was active after sql changes.
This likely has something to do with the auth_cache value.
Try on a fresh user, change it, try 2 minutes before auth_cache would expire, and then again 2 minutes after.
That is it, I retested after my TTL expired and it's fine, picked up new value without a restart.
Noel,
Thanks a lot for your help. But with this behavior, we will have to modify our scripts to perhaps clear up/reset the cache after changing User Quotas ....
M.A.
Noel Butler wrote:
On Sun, 2009-09-13 at 07:25 +1000, Noel Butler wrote:
On Sat, 2009-09-12 at 10:06 -0400, Mario Antonio wrote:
Has anybody noticed this behavior when using maildir quota with Version 1.2.4:
When I change quota at the SQL level (per user), that quota becomes active once Dovecot is restarted. Until then it keeps the previous quota assigned. I do not remember seeing this behavior in previous versions --quota was active after sql changes.
This likely has something to do with the auth_cache value.
Try on a fresh user, change it, try 2 minutes before auth_cache would expire, and then again 2 minutes after.
That is it, I retested after my TTL expired and it's fine, picked up new value without a restart.
On Sat, 2009-09-12 at 18:56 -0400, Mario Antonio wrote:
Noel,
Thanks a lot for your help. But with this behavior, we will have to modify our scripts to perhaps clear up/reset the cache after changing User Quotas ....
Hi Mario,
You could try setting it to value of "0" not too sure on what performance impact you might get though (Timo??) As it asks the database every time you connect, if you run replication and query localhost, I doubt anything degrading, if you don't run replication and your mysql server is real busy, you might experience a slight to noticeable performance impact.
Cheers Noel
On Sep 12, 2009, at 6:56 PM, Mario Antonio wrote:
Thanks a lot for your help. But with this behavior, we will have to modify our scripts to
perhaps clear up/reset the cache after changing User Quotas ....
You can reset auth cache by sending dovecot-auth process SIGHUP. I'd
guess changing quota values is somewhat rare so this shouldn't be much
of a performance issue. Anyway, the whole point of auth cache is to
cache the lookups so everything is working as it should..
Timo,
Thanks ! Just looking for a way to scripting the resetting of the auth-cache .. I noticed the dovecot-auth process does not have a PID file as the Dovecot master has (or perhaps I missed it ...)
In a debian machine (running Version 1.2.4) Could I just grab the pid number from the auth socket:
ls /var/run/dovecot/auth-worker* | sed 's/.*auth-worker\.//' 10650
cat /var/run/dovecot/master.pid 10649
ps -ef | grep auth root 10650 10649 0 Sep12 ? 00:00:03 dovecot-auth root 10656 10649 0 Sep12 ? 00:00:00 dovecot-auth -w
These are the contents of /var/run/dovecot/ (3 sockets and one PID file : auth-master auth-worker.10650 dict-server master.pid
Regards,
M.A.
Timo Sirainen wrote:
On Sep 12, 2009, at 6:56 PM, Mario Antonio wrote:
Thanks a lot for your help. But with this behavior, we will have to modify our scripts to perhaps clear up/reset the cache after changing User Quotas ....
You can reset auth cache by sending dovecot-auth process SIGHUP. I'd guess changing quota values is somewhat rare so this shouldn't be much of a performance issue. Anyway, the whole point of auth cache is to cache the lookups so everything is working as it should..
On Sep 14, 2009, at 11:48 PM, Mario Antonio wrote:
Thanks ! Just looking for a way to scripting the resetting of the auth-cache .. I noticed the dovecot-auth process does not have a PID file as the
Dovecot master has (or perhaps I missed it ...)
Right, it doesn't. Hmm. Wonder if there should .. Kind of annoying to
pollute multiple PIDs there.
In a debian machine (running Version 1.2.4) Could I just grab the pid number from the auth socket:
ls /var/run/dovecot/auth-worker* | sed 's/.*auth-worker\.//'
No, that's auth worker's PID and the auth cache is in the main dovecot- auth process.
I just do killall -HUP dovecot-auth :)
participants (3)
-
Mario Antonio
-
Noel Butler
-
Timo Sirainen