Re: [Dovecot] fd limit 1024 is lower in dovecot-1.1.1

2008-06-29 Thread Daniel Black
On Sun, 29 Jun 2008 03:53:54 pm Zhang Huangbin wrote:
 Hi, all.

 I just upgrade from 1.0.15 to 1.1.1 in a test box(RHEL 5.2, x86_64).

 after upgrade, i got this warning msg:

 8 
 # /etc/init.d/dovecot restart
 Stopping Dovecot Imap: [  OK  ]
 Starting Dovecot Imap: Warning: fd limit 1024 is lower than what Dovecot
 can use under full load (more than 1280). Either grow the limit or
 change login_max_processes_count and max_mail_processes settings
[  OK  ]
 8 

 but i changed either login_max_processes_count and max_mail_processes
 to 2048, it raised the same msg.

change may not mean increase

 How can i solove this issue? 

/etc/security/limits.conf to increase the nofiles or possibly decrese the 
process counts.


-- 

Daniel Black
--
Proudly a Gentoo Linux User.
Gnu-PG/PGP signed and encrypted email preferred
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x76677097
GPG Signature D934 5397 A84A 6366 9687  9EB2 861A 4ABA 7667 7097


signature.asc
Description: This is a digitally signed message part.


[Dovecot] quota_warning script

2008-06-29 Thread Nicolas Letellier
Hello.

I'm reading http://wiki.dovecot.org/Quota/1.1 one last time before my upgrade, 
and I have a question about quota_warning option. Which type of script must we 
use for this example:

quota_warning = storage=95%% /usr/local/bin/quota-warning.sh 95

What the script must doing? It sends an email? It deletes some emails?

Thanks!

-- 
 -Nicolas.


Re: [Dovecot] quota_warning script

2008-06-29 Thread Nicolas Letellier
On Sun, 29 Jun 2008 09:02:19 +0200
Anders [EMAIL PROTECTED] wrote:

 Nicolas Letellier wrote:
  What the script must doing? It sends an email? It deletes some emails?
 

 
 http://dovecot.org/list/dovecot/2008-June/031456.html
 
 
 Anders
 
Thanks! Now, it could be a good idea to add this example in dovecot wiki.

-- 
 -Nicolas.


Re: [Dovecot] fd limit 1024 is lower in dovecot-1.1.1

2008-06-29 Thread Daniel L. Miller

Zhang Huangbin wrote:

Hi, all.

I just upgrade from 1.0.15 to 1.1.1 in a test box(RHEL 5.2, x86_64).

after upgrade, i got this warning msg:

8 
# /etc/init.d/dovecot restart
Stopping Dovecot Imap: [  OK  ]
Starting Dovecot Imap: Warning: fd limit 1024 is lower than what 
Dovecot can use under full load (more than 1280). Either grow the 
limit or change login_max_processes_count and max_mail_processes settings

  [  OK  ]
8 

but i changed either login_max_processes_count and max_mail_processes
to 2048, it raised the same msg. How can i solove this issue?

I'm just guessing - but reading that warning it appears to me that 
Dovecot is saying that as it is configured, it can consume more O/S 
resources (I assume fd is file descriptors) than the O/S is currently 
configured for.  So you need to DECREASE your dovecot max processes to 
decrease the (potential) system demands - or increase your O/S settings.


Daniel


[Dovecot] Quota Check: fs with multiple noenforcing mount point

2008-06-29 Thread Grandy Fu

Hi,

It seems my previous mail has been lost, I apologize if this is a duplicate.

I am using Dovecot 1.1.1 with user's INBOX in /var/mail and other 
folders in their home directories. I have setup  file system  quota on 
/var/mail to limit their usage. I would like dovecot to display such 
information in IMAP client and ignore all others.


OS: Solaris 10
Dovecot version : 1.1.1
file system of /var/mail : NFS from Solaris
file system of /home : other NFS server that not support rquotad.


Here is my setting that works:

plugin {
quota  = fs:INBOX:mount=/var/mail
quota2  = fs:home:noenforcing:mount=/home/h1
}
--

Unfortunately, I have many different mount points for different users, 
so I changed my settings to:

---
plugin {
quota  = fs:INBOX:mount=/var/mail
quota2  = fs:home:noenforcing:mount=/home/h1
quota3  = fs:home:noenforcing:mount=/home/h2
quota4  = fs:home:noenforcing:mount=/home/h3
}
--

The result is... Devocolt is not able to get quota information anymore.
Any suggestions?





Re: [Dovecot] fd limit 1024 is lower in dovecot-1.1.1

2008-06-29 Thread Zhang Huangbin

Daniel L. Miller wrote:

Zhang Huangbin wrote:

Hi, all.

I just upgrade from 1.0.15 to 1.1.1 in a test box(RHEL 5.2, x86_64).

after upgrade, i got this warning msg:

8 
# /etc/init.d/dovecot restart
Stopping Dovecot Imap: [  OK  ]
Starting Dovecot Imap: Warning: fd limit 1024 is lower than what 
Dovecot can use under full load (more than 1280). Either grow the 
limit or change login_max_processes_count and max_mail_processes 
settings

  [  OK  ]
8 

but i changed either login_max_processes_count and max_mail_processes
to 2048, it raised the same msg. How can i solove this issue?

I'm just guessing - but reading that warning it appears to me that 
Dovecot is saying that as it is configured, it can consume more O/S 
resources (I assume fd is file descriptors) than the O/S is 
currently configured for.  So you need to DECREASE your dovecot max 
processes to decrease the (potential) system demands - or increase 
your O/S settings.


Daniel



I think so.

I just decrease the processes, it works now.

Thanks Daniel and all replies. :)


--
Best Regards.

Zhang Huangbin

- Mail Server Solution for Red Hat(R) Enterprise Linux  CentOS 5.x:
 http://rhms.googlecode.com/



Re: [Dovecot] Search over big folder hierarchy (was: Global FTS index?)

2008-06-29 Thread Asheesh Laroia

On Tue, 24 Jun 2008, Timo Sirainen wrote:

Hmm. Or v1.2 has virtual mailboxes - you could create a single virtual 
mailbox from all your other mailboxes and then search it. I think if 
Squat is enabled it'll create a single index from all the mails. I'm not 
sure if I want to leave it like that though..


I hope that the index is shared - that you index the index by inode 
number, not filename or message UID in a mailbox, since that way you can 
avoid duplicate storage of index data between virtual mailboxes and normal 
ones.


I have also been thinking about making Squat indexes global for all 
mailboxes. If done well it should reduce disk space as well as enable 
fast multi-mailbox searches, but I'm a bit worried about memory usage 
and other slowness when updating the index. The Squat building/updating 
could use more work, but I haven't yet figured out a great solution for 
it.


Well, I think it would be okay - deploy it and we'll all tell you. (-;

(As always, thanks for this amazing software.)

-- Asheesh.

--
The wonderful thing about a dancing bear is not how well he dances,
but that he dances at all.