[Dovecot] Dovecot vs Exim file locking
Hi all: We're planning to deploy a large e-mail system storing maildirs in a NAS system through NFS. One of the options we're thinking on is using Dovecot+EXIM. As far as I've read in both project's documentation, both services implement locking allowing multiple servers to access the same maildirs in order to distribute the service load. However, I can't find any information explaining whether both locking mechanisms are compatible, whether any additional configuration is needed both in Dovecot and/or EXIM, or even whether any locking synchronization between both services is needed/recommendable at all. The only remote clue I've found is that, according to Dovecot docs: Because Dovecot uses its own non-standard locking (dovecot-uidlist.lock dotlock file), other MUAs accessing the maildir don't support it. (but EXIM is not a MUA, anyway) Anyhow theoretically MailDir could even be considered free of locking problems, but I'm not sure of the real implications of putting together several Exim and Dovecot installations pointing to the same NFS filesystem. Any knowledge/experience/link/clue on this would be greatly appreciated. Thanks in advance, Daniel Campos
Re: [Dovecot] Dovecot vs Exim file locking
On Sex, 18 Dez 2009, Daniel Campos wrote: We're planning to deploy a large e-mail system storing maildirs in a NAS system through NFS. One of the options we're thinking on is using Dovecot+EXIM. As far as I've read in both project's documentation, both services implement locking allowing multiple servers to access the same maildirs in order to distribute the service load. However, I can't find any information explaining whether both locking mechanisms are compatible, whether any additional configuration is needed both in Dovecot and/or EXIM, or even whether any locking synchronization between both services is needed/recommendable at all. The only remote clue I've found is that, according to Dovecot docs: Because Dovecot uses its own non-standard locking (dovecot-uidlist.lock dotlock file), other MUAs accessing the maildir don't support it. (but EXIM is not a MUA, anyway) Anyhow theoretically MailDir could even be considered free of locking problems, but I'm not sure of the real implications of putting together several Exim and Dovecot installations pointing to the same NFS filesystem. Any knowledge/experience/link/clue on this would be greatly appreciated. As far as I know, maildir does not require locking. I used sometime exim + dovecot without problems. Now I use dovecot's deliver, by doing that you'll certainly have no problems. -- Genius doesn't work on an assembly line basis. You can't simply say, Today I will be brilliant. -- Kirk, The Ultimate Computer, stardate 4731.3 Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: [Dovecot] Dovecot vs Exim file locking
On Dec 18, 2009, at 8:41 AM, Daniel Campos wrote: We're planning to deploy a large e-mail system storing maildirs in a NAS system through NFS. One of the options we're thinking on is using Dovecot+EXIM. As far as I've read in both project's documentation, both services implement locking allowing multiple servers to access the same maildirs in order to distribute the service load. Mail deliveries don't require any locks with maildir. But for Dovecot, be sure to read http://wiki.dovecot.org/NFS
Re: [Dovecot] imap-login crashes after upgrade to Dovecot 1.2.8 Linux 64-bit
On 18/12/2009 01:11, Timo Sirainen wrote: On Dec 17, 2009, at 8:01 PM, Chris Wakelin wrote: Dec 18 00:27:58 imap-login: Info: Disconnected: Connection queue full (auth failed, 1 attempts): user=user0, method=PLAIN, rip=ip0, lip=134.225.32.156, TLS Dec 18 00:27:58 imap-login: Panic: file ioloop.c: line 39 (io_add): assertion failed: (fd = 0) I guess the crash is caused by the connection queue full. I'll see about fixing the crash, but you shouldn't let it get full in any case. So increase your login_max_connections value. That's puzzling, I thought it was supposed to fire up another imap-login process (up to login_max_processes_count)? We have something in the region of 1000 concurrent connections and login_max_processes_count * login_max_connections = 128 * 256 should be enough for 32000+ of them! Would it be better to have login_max_connections = 1024 (or even higher)? I'm also confused as to why we never saw the problem on the Solaris box (with more connections as it was during term time). At the moment I'm running with login_process_per_connection = yes but I'm a little concerned about the increased CPU load (I could probably add more virtual CPUs, but there are apparently some issues with 64-lit Linux on multiple CPUs in VMWare ESX 3.5.x). Best Wishes, Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wake...@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Re: [Dovecot] imap-login crashes after upgrade to Dovecot 1.2.8 Linux 64-bit
On Fri, 2009-12-18 at 14:56 +, Chris Wakelin wrote: I guess the crash is caused by the connection queue full. I'll see about fixing the crash, but you shouldn't let it get full in any case. So increase your login_max_connections value. That's puzzling, I thought it was supposed to fire up another imap-login process (up to login_max_processes_count)? It's supposed to, yes, but it's been buggy for a long time and I haven't figured out how to fix it. v2.0 should finally fix it.. We have something in the region of 1000 concurrent connections and login_max_processes_count * login_max_connections = 128 * 256 should be enough for 32000+ of them! Would it be better to have login_max_connections = 1024 (or even higher)? Yes. If you have only one CPU/core you shouldn't have more than 2 login processes. I'm also confused as to why we never saw the problem on the Solaris box (with more connections as it was during term time). It was probably doing a better job than Linux of distributing connections to processes. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] imap-login crashes after upgrade to Dovecot 1.2.8 Linux 64-bit
On 18/12/2009 15:08, Timo Sirainen wrote: We have something in the region of 1000 concurrent connections and login_max_processes_count * login_max_connections = 128 * 256 should be enough for 32000+ of them! Would it be better to have login_max_connections = 1024 (or even higher)? Yes. If you have only one CPU/core you shouldn't have more than 2 login processes. I'm also confused as to why we never saw the problem on the Solaris box (with more connections as it was during term time). It was probably doing a better job than Linux of distributing connections to processes. Ah! That makes sense, as the Solaris box had four processors and 4 * 256 would have probably been enough most of the time. It wouldn't surprise me if the Solaris kernel is better at this as well. Best Wishes, Chris -- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wake...@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Re: [Dovecot] Upgrade 1.0-1.2 dbox mysql
On tor 17 dec 2009 21:30:37 CET, Bradley Giesbrecht wrote Most everything seems to work but my webmail (roundcube) clients are not seeing their subscribed folders. roundcube 0.3.1 settings server settings Use IMAP Subscriptions (togle) -- xpoint pgpR5bCrVR5rM.pgp Description: PGP digital signatur
[Dovecot] lot's of timeouts
Hi, since some time ago we do have a lot of timeouts connecting to our imap/po3 server. This week I switched the whole system to a new dual quadcore xeon, 24GB RAM, SAS2 RAID-10. (SUN Fire 4170) But the mailclients (mostly thunderbird and apple mail) still reporte the timeouts by accessing the mailboxes. The server is doing smtp, imap/pop3, webmailsystem and spam/antivirus-checking all together. (RH EL 5, sendmail, horde, mysql, mailscanner, spamassassin) We use the original RH dovecot-1.0.7, mbox-format and mailboxes up to 4 GB ... (historicaly grown ...) So where to start debugging the imap/pop3 timeouts? What information may I provide, which doc may I read? Thanks for helping me to find and fix the problem. Best regards Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt
Re: [Dovecot] lot's of timeouts
On Dec 18, 2009, at 10:56 AM, Götz Reinicke - IT-Koordinator wrote: But the mailclients (mostly thunderbird and apple mail) still reporte the timeouts by accessing the mailboxes. The server is doing smtp, imap/pop3, webmailsystem and spam/antivirus-checking all together. (RH EL 5, sendmail, horde, mysql, mailscanner, spamassassin) We use the original RH dovecot-1.0.7, mbox-format and mailboxes up to 4 GB ... (historicaly grown ...) Have you set mbox_very_dirty_syncs=yes? So where to start debugging the imap/pop3 timeouts? What information may I provide, which doc may I read? Anything in logs? Anyway my guess is that it spends all the time reading those 4 GB mailboxes..
Re: [Dovecot] Upgrade 1.0-1.2 dbox mysql
On Dec 18, 2009, at 7:26 AM, Benny Pedersen wrote: On tor 17 dec 2009 21:30:37 CET, Bradley Giesbrecht wrote Most everything seems to work but my webmail (roundcube) clients are not seeing their subscribed folders. roundcube 0.3.1 settings server settings Use IMAP Subscriptions (togle) Thank you. The problem ended up being that since my upgrade from 1.1x to 1.2x yesterday the mail box locations have moved inside a directory named mailboxes. I don't have the word mailboxes in any configuration I set so dovecot 1.2 must have added this. This was not the case with my dovecot 1.1 before the upgrade. I had: /opt/local/var/mail/domain/user/dbox/INBOX now: /opt/local/var/mail/domain/user/dbox/mailboxes/INBOX Since I could not figure out how to stop this behavior I just went with it and moved everyones old mailboxes to the new location in the wee hours of this morning. I renamed the mailboxes that were created yesterday before doing so. Thank goodness I have less then a hundred imap users. I wish I understood dovecots directory vars better. What is mail_location used for? What is the userdb_home returned from my passdb and userdb used for? Would userdb_home ever not start with the complete mail_location path? Reading the docs leaves me puzzled and I end up just trying things till something works. I'm updating the MacPorts dovecot port to 1.2 and I'd like to be able to explain to the MacPorts user base the changes to dovecot 1.1x configurations needed for a easy upgrade. Regards, Bradley Giesbrecht
Re: [Dovecot] lot's of timeouts
Hi Timo, Timo Sirainen schrieb: On Dec 18, 2009, at 10:56 AM, Götz Reinicke - IT-Koordinator wrote: But the mailclients (mostly thunderbird and apple mail) still reporte the timeouts by accessing the mailboxes. The server is doing smtp, imap/pop3, webmailsystem and spam/antivirus-checking all together. (RH EL 5, sendmail, horde, mysql, mailscanner, spamassassin) We use the original RH dovecot-1.0.7, mbox-format and mailboxes up to 4 GB ... (historicaly grown ...) Have you set mbox_very_dirty_syncs=yes? grep mbox_very_dirty_syncs /etc/dovecot.conf #mbox_very_dirty_syncs = no so, I think no is the default. Setting this to yes is may be faster? So where to start debugging the imap/pop3 timeouts? What information may I provide, which doc may I read? Anything in logs? Anyway my guess is that it spends all the time reading those 4 GB mailboxes.. With that guess, you are not the only one ... beside my guts ... ;-) If I do have the time, I'd like to switch over to e.g. maildir /Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt
Re: [Dovecot] lot's of timeouts
On Dec 18, 2009, at 11:08 AM, Götz Reinicke - IT-Koordinator wrote: We use the original RH dovecot-1.0.7, mbox-format and mailboxes up to 4 GB ... (historicaly grown ...) Have you set mbox_very_dirty_syncs=yes? grep mbox_very_dirty_syncs /etc/dovecot.conf #mbox_very_dirty_syncs = no so, I think no is the default. Setting this to yes is may be faster? Are you using Dovecot deliver? If not, setting this to yes will help a lot. Anything in logs? Anyway my guess is that it spends all the time reading those 4 GB mailboxes.. With that guess, you are not the only one ... beside my guts ... ;-) If I do have the time, I'd like to switch over to e.g. maildir Yeah, maildir would be a good idea.
Re: [Dovecot] lot's of timeouts
Timo Sirainen schrieb: On Dec 18, 2009, at 11:08 AM, Götz Reinicke - IT-Koordinator wrote: We use the original RH dovecot-1.0.7, mbox-format and mailboxes up to 4 GB ... (historicaly grown ...) Have you set mbox_very_dirty_syncs=yes? grep mbox_very_dirty_syncs /etc/dovecot.conf #mbox_very_dirty_syncs = no so, I think no is the default. Setting this to yes is may be faster? Are you using Dovecot deliver? If not, setting this to yes will help a lot. Nop, grep procmail /etc/mail/sendmail.mc define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl MAILER(procmail)dnl Anything in logs? Anyway my guess is that it spends all the time reading those 4 GB mailboxes.. With that guess, you are not the only one ... beside my guts ... ;-) If I do have the time, I'd like to switch over to e.g. maildir Yeah, maildir would be a good idea. 2010... /Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt
Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8
On Nov 25, 2009, at 4:51 PM, Stephan Bosch wrote: Hello Dovecot users, I am getting closer to new releases for Sieve and ManageSieve for Dovecot v1.2.8. However, the release for Sieve includes a large restructuring of the sources to improve extension handling and to remove global state. That is why I first provide a few pre-releases for you to check first: Sieve http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz.sig Feel free to test these release candidates and please notify me when you incur any problems. The real releases will follow this weekend. Stephen, How are you doing regarding the real releases, specifically dovecot-1.2-sieve-0.1.14 ? The pre release is/was a bit confusing as it contains a dovecot-1.2-sieve-0.1.13 folder within the dovecot-1.2- sieve-0.1.14pre.tar.gz archive. Thank you, Bruce
Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8
Bruce Bodger wrote: On Nov 25, 2009, at 4:51 PM, Stephan Bosch wrote: Hello Dovecot users, I am getting closer to new releases for Sieve and ManageSieve for Dovecot v1.2.8. However, the release for Sieve includes a large restructuring of the sources to improve extension handling and to remove global state. That is why I first provide a few pre-releases for you to check first: Sieve http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz.sig Feel free to test these release candidates and please notify me when you incur any problems. The real releases will follow this weekend. Stephen, How are you doing regarding the real releases, specifically dovecot-1.2-sieve-0.1.14 ? The pre release is/was a bit confusing as it contains a dovecot-1.2-sieve-0.1.13 folder within the dovecot-1.2-sieve-0.1.14pre.tar.gz archive. Well, I got sued, so that took some of my attention. I'll tend to this tomorrow morning. Regards, Stephan.
Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8
Original-Nachricht Datum: Fri, 18 Dec 2009 22:21:21 +0100 Von: Stephan Bosch step...@rename-it.nl An: Bruce Bodger bbod...@bodcon.com CC: Dovecot Mailing List dovecot@dovecot.org Betreff: Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8 Bruce Bodger wrote: On Nov 25, 2009, at 4:51 PM, Stephan Bosch wrote: Hello Dovecot users, I am getting closer to new releases for Sieve and ManageSieve for Dovecot v1.2.8. However, the release for Sieve includes a large restructuring of the sources to improve extension handling and to remove global state. That is why I first provide a few pre-releases for you to check first: Sieve http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.14pre.tar.gz.sig Feel free to test these release candidates and please notify me when you incur any problems. The real releases will follow this weekend. Stephen, How are you doing regarding the real releases, specifically dovecot-1.2-sieve-0.1.14 ? The pre release is/was a bit confusing as it contains a dovecot-1.2-sieve-0.1.13 folder within the dovecot-1.2-sieve-0.1.14pre.tar.gz archive. Well, I got sued, so that took some of my attention. How did it end for you? I hope, I wish it ended good for you? I'll tend to this tomorrow morning. Regards, Stephan. Steve -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser
Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8
Steve wrote: Well, I got sued, so that took some of my attention. How did it end for you? I hope, I wish it ended good for you? Yes, for some reason the lawsuit was withdrawn the day before, probably due to our written defense. I don't know. At least it's gone for now. Regards, Stephan.
[Dovecot] Maildir on NFS - attribute caching question
Hi Timo, We've been running Dovecot with Maildir on NFS for quite a while - since back in the 1.0 days I believe. I'm somewhat new here. Anyway... The Wiki article on NFS states that 1.1 and newer will flush attribute caches if necessary with mail_nfs_storage=yes. We're running 1.2.8 with that set, as well as mail_nfs_index=yes, mmap_disable=yes and fsync_disable=no. We have a pool of POP/IMAP and SMTP machines that are accessing the maildirs, and can't guarantee any sort of user session affinity to a particular host. We also mount our NFS shares with 'noac', which is what I'm writing to ask about. I'd like to stop doing that for performance reasons. Do you see any issues with taking that out of the mount options, given our environment? Thanks, -Brad
[Dovecot] dovecot: pipe() failed: Too many open files
In the past few months we've been having increasing problems with dovecot timing out pop3 logins. As best I can tell it gets to the point where it won't accept any new pop3 logins. The error in the mail log is: dovecot: pipe() failed: Too many open files I've researched this problem a number of times, usually I see suggestions to increase ulimit. I've done this a number of times, all the way up to: ulimit -n 8192 I've put that in the init script right above the daemon start line. So far it hasn't helped. In addition, when looking at lsof, it doesn't seem like we're anywhere near the actual limit. for example, last time dovecot only had 1032 files open. Does anyone have any idea what could be causing the error? Or what else I can try to figure this out? Thank you, JW -- -- System Administrator - Cedar Creek Software http://www.cedarcreeksoftware.com
Re: [Dovecot] Maildir on NFS - attribute caching question
On Dec 18, 2009, at 4:42 PM, Brandon Davidson wrote: The Wiki article on NFS states that 1.1 and newer will flush attribute caches if necessary with mail_nfs_storage=yes. We're running 1.2.8 with that set, as well as mail_nfs_index=yes, mmap_disable=yes and fsync_disable=no. We have a pool of POP/IMAP and SMTP machines that are accessing the maildirs, and can't guarantee any sort of user session affinity to a particular host. We also mount our NFS shares with 'noac', which is what I'm writing to ask about. I'd like to stop doing that for performance reasons. Do you see any issues with taking that out of the mount options, given our environment? Dovecot's NFS cache flushing doesn't work perfectly. But I think some/most/all of those conditions exist also when attribute cache is disabled. Or maybe not. I can't really remember anymore what I read in the kernel code :) And that was only for Linux and FreeBSD, don't know about other OSes. The issue was about directory entry caching, I don't remember if attribute cache also disabled it. Anyway.. I think you should just try enabling attribute cache and if things start breaking more, disable it again.
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On Dec 18, 2009, at 4:47 PM, JW wrote: I've researched this problem a number of times, usually I see suggestions to increase ulimit. I've done this a number of times, all the way up to: ulimit -n 8192 I've put that in the init script right above the daemon start line. What exactly is the daemon start line? Many Linux distros override ulimit in their internal scripts. If you're using Linux, you could check if dovecot process really has 8192 limit: cat /proc/`pidof dovecot`/limits | grep 'Max open'
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On Friday 18 December 2009 16:00:48 Timo Sirainen wrote: On Dec 18, 2009, at 4:47 PM, JW wrote: I've researched this problem a number of times, usually I see suggestions to increase ulimit. I've done this a number of times, all the way up to: ulimit -n 8192 I've put that in the init script right above the daemon start line. What exactly is the daemon start line I'm sorry, I forgot to specify that I was using Debian Linux: case $1 in start) if grep protocols /etc/dovecot/dovecot.conf | sed 's/#.*$//' | tr -d '' | \ egrep -q '[^#]*(\bpop3s?\b|\bimaps?\b)'; then if [ -x /usr/lib/dovecot/imap-login -a -x /usr/lib/dovecot/imap ] \ || [ -x /usr/lib/dovecot/pop3-login -a -x /usr/lib/dovecot/pop3 ]; then echo -n Starting $DESC: $NAME ulimit -n 8192 start-stop-daemon --start --quiet --oknodo --exec $DAEMON echo . fi fi ;; stop) echo -n Stopping $DESC: $NAME start-stop-daemon --stop --quiet --oknodo --exec $DAEMON echo . ;; ? Many Linux distros override ulimit in their internal scripts. If you're using Linux, you could check if dovecot process really has 8192 limit: cat /proc/`pidof dovecot`/limits | grep 'Max open' I've seen this suggestion on the web a few times, but there's no such directory, /proc/`pidof dovecot`/limits or /proc/*/limits for that matter pidof dovecot shows the pid for: /usr/sbin/dovecot I've tried grep -i max and grep -i open in the /proc/$pid/* directory for every pid of every dovecot process on the system, none of the files in there contain either word. mail:/var/log# ps auxw | grep dove root 23299 0.0 0.0 1948 648 ?Ss 00:41 0:07 /usr/sbin/dovecot root 23300 0.0 0.2 8752 2700 ?S00:41 0:05 dovecot-auth mail:/var/log# ls /proc/23299 attr cmdline cwd exe maps mounts oom_adjroot stat status wchan auxv cpuset environ fd mem mountstats oom_score smaps statm task Is there a different place I should put the ulimit? JW -- -- System Administrator - Cedar Creek Software http://www.cedarcreeksoftware.com
[Dovecot] expire db(s)?
with two separate dovecot/backend servers accessing one central mysql server, will it be ok to have them both use the same expires table? Or will that confuse the actual dovecot --exec-mail ext /usr/local/libexec/dovecot/expire-tool.sh cronjob since some of the entries mailboxes won't exist locally? Ben
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On Dec 18, 2009, at 5:46 PM, JW wrote: I'm sorry, I forgot to specify that I was using Debian Linux: echo -n Starting $DESC: $NAME ulimit -n 8192 start-stop-daemon --start --quiet --oknodo --exec $DAEMON Well, this seemed to work in Debian unstable.. So maybe the problem is that something just causes Dovecot to eat all available file descriptors. When it happens again you should get the lsof output of dovecot and save it. Also you never mentioned your Dovecot version. It's possible it's already been fixed in recent versions. ? Many Linux distros override ulimit in their internal scripts. If you're using Linux, you could check if dovecot process really has 8192 limit: cat /proc/`pidof dovecot`/limits | grep 'Max open' I've seen this suggestion on the web a few times, but there's no such directory, /proc/`pidof dovecot`/limits or /proc/*/limits for that matter I guess you've old enough kernel that it doesn't support it.
Re: [Dovecot] dovecot: pipe() failed: Too many open files
JW wrote: On Friday 18 December 2009 16:00:48 Timo Sirainen wrote: On Dec 18, 2009, at 4:47 PM, JW wrote: I've researched this problem a number of times, usually I see suggestions to increase ulimit. I've done this a number of times, all the way up to: ulimit -n 8192 I've put that in the init script right above the daemon start line. What exactly is the daemon start line I'm sorry, I forgot to specify that I was using Debian Linux: case $1 in start) if grep protocols /etc/dovecot/dovecot.conf | sed 's/#.*$//' | tr -d '' | \ egrep -q '[^#]*(\bpop3s?\b|\bimaps?\b)'; then if [ -x /usr/lib/dovecot/imap-login -a -x /usr/lib/dovecot/imap ] \ || [ -x /usr/lib/dovecot/pop3-login -a -x /usr/lib/dovecot/pop3 ]; then echo -n Starting $DESC: $NAME ulimit -n 8192 start-stop-daemon --start --quiet --oknodo --exec $DAEMON echo . fi fi ;; stop) echo -n Stopping $DESC: $NAME start-stop-daemon --stop --quiet --oknodo --exec $DAEMON echo . ;; ? Many Linux distros override ulimit in their internal scripts. If you're using Linux, you could check if dovecot process really has 8192 limit: cat /proc/`pidof dovecot`/limits | grep 'Max open' I've seen this suggestion on the web a few times, but there's no such directory, /proc/`pidof dovecot`/limits or /proc/*/limits for that matter pidof dovecot shows the pid for: /usr/sbin/dovecot I've tried grep -i max and grep -i open in the /proc/$pid/* directory for every pid of every dovecot process on the system, none of the files in there contain either word. mail:/var/log# ps auxw | grep dove root 23299 0.0 0.0 1948 648 ?Ss 00:41 0:07 /usr/sbin/dovecot root 23300 0.0 0.2 8752 2700 ?S00:41 0:05 dovecot-auth mail:/var/log# ls /proc/23299 attr cmdline cwd exe maps mounts oom_adjroot stat status wchan auxv cpuset environ fd mem mountstats oom_score smaps statm task Is there a different place I should put the ulimit? JW You could try: /etc/security/limits.conf your_dovecot_user soft nofile 524288 your_dovecot_user hard nofile 524288 Not sure if instead of your_dovecot_user, you should increase the limits for the root user ?? Regards, Mario Antonio
Re: [Dovecot] expire db(s)?
On Dec 18, 2009, at 5:57 PM, b...@electricembers.net wrote: with two separate dovecot/backend servers accessing one central mysql server, will it be ok to have them both use the same expires table? Or will that confuse the actual dovecot --exec-mail ext /usr/local/libexec/dovecot/expire-tool.sh cronjob since some of the entries mailboxes won't exist locally? It'll break. If userdb lookup fails, expire-tool thinks that the user no longer exists and deletes the row from database. If it succeeds but the mail directory doesn't exist, it'll think the mailbox was deleted and deletes the row from database.
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On Dec 18, 2009, at 6:12 PM, Mario Antonio wrote: JW wrote:You could try: /etc/security/limits.conf your_dovecot_user soft nofile 524288 your_dovecot_user hard nofile 524288 I think these are read by PAM when user logs in. Dovecot never uses them. I'm not sure if even setting root's limits here will affect software started by init.d scripts at system startup.
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On 12/18/2009, JW (j...@mailsw.com) wrote: I'm sorry, I forgot to specify that I was using Debian Linux: You also forgot the bare neceesities, like dovecot version, dovecot -n output and log entries exhibiting the problem. I'm actually amazed at how many people post on support lists and say 'Help! Its not working!! What did I do wrong?!' - do they really expect meaningful help? Even more amazing, on this list Timo can often divine the answer anyway...
Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8
Original-Nachricht Datum: Fri, 18 Dec 2009 22:31:02 +0100 Von: Stephan Bosch step...@rename-it.nl An: Dovecot Mailing List dovecot@dovecot.org Betreff: Re: [Dovecot] Release candidates for Sieve v0.1.14 and ManageSieve v0.11.10 for Dovecot v1.2.8 Steve wrote: Well, I got sued, so that took some of my attention. How did it end for you? I hope, I wish it ended good for you? Yes, for some reason the lawsuit was withdrawn the day before, probably due to our written defense. I don't know. At least it's gone for now. I don't know about what it was but I hope they don't try again. Just continue your normal life and don't care about them. My daddy used to say (he passed away this year in February): Dear son. Don't touch shit. It will only stink more! So don't care about the ones that have tried to sue you. The less you care about them the better for you (I guess). Regards, Stephan. Steve -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: [Dovecot] dovecot: pipe() failed: Too many open files
On Fre, 2009-12-18 at 18:32 -0500, Charles Marcus wrote: On 12/18/2009, JW (j...@mailsw.com) wrote: I'm sorry, I forgot to specify that I was using Debian Linux: You also forgot the bare neceesities, like dovecot version, dovecot -n output and log entries exhibiting the problem. And for the current case looking into /proc/$(pidof dovecot)/fd should show all open fds (and $(ls -1 /proc/$(pidof dovecot)/fd | wc -l) should be somewhat near the limit). I'm actually amazed at how many people post on support lists and say 'Help! Its not working!! What did I do wrong?!' - do they really expect meaningful help? Even more amazing, on this list Timo can often divine the answer anyway... He has probably am extremely good crystal ball;-) Bernd -- mobil: +43 664 4416156 http://bernd.petrovitsch.priv.at/ Linux Software Entwicklung, Beratung und Dienstleistungen
