Re: [Dovecot] stopping dovecot
On Sun, 27 Jul 2008, Kai Schaetzl wrote: It does kill everything. Not for me, not with the 1.07 I have in CentOS 5.2. When I ran service dovecot restart (or stop) in that situation it did *not* kill all the pop3-login children. I had to use killall. It is normal for some services to terminate te main process, but leave active children alive. Especially for pop3 processes, as they can be considered to terminate soon due to protocol design. Same goes for ssh for example. You can kill (stop, or restart) the main sshd, without killing the sessions currently running. Exim also does similar things. Killing all children could result in data corruption, since seen flags etc. need to be saved before exiting. The restarting after 2 seconds thing I just saw in another mail can possibly be prevented by using the appropriate setsockopts on the listen port (SO_REUSEADDR in this case, if I'm not mistaken). This may however very well be a Linux-specific solution. Regards, Maarten Bezemer
Re: [Dovecot] stopping dovecot
Maarten Bezemer wrote on Sun, 27 Jul 2008 11:43:06 +0200 (CEST): It is normal for some services to terminate te main process, but leave active children alive. That may be so, but Timo claimed the opposite (as I read his response). I'm merely pointing out that I cannot see the behavior that Timo states. If you want to get rid of all these processes you have to killall. Especially for pop3 processes, as they can be considered to terminate soon due to protocol design. Can you elaborate on this? Also, have a look at the thread I mentioned. Dozens pop3-login processes were staying sleeping for 5 or more hours. There was no remote part anymore. Doesn't sound like they terminated soon due to protocol design. Same goes for ssh for example. You can kill (stop, or restart) the main sshd, without killing the sessions currently running. Yes. Right you are. And especially with ssh it's quite helpful ;-) The restarting after 2 seconds thing I just saw in another mail can possibly be prevented by using the appropriate setsockopts on the listen port (SO_REUSEADDR in this case, if I'm not mistaken). This may however very well be a Linux-specific solution. That concerns the tidying up? In my case it wasn't a problem with still occupied ports, I checked for presence of processes. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: [Dovecot] stopping dovecot
On Sun, 2008-07-27 at 13:31 +0200, Kai Schaetzl wrote: Maarten Bezemer wrote on Sun, 27 Jul 2008 11:43:06 +0200 (CEST): It is normal for some services to terminate te main process, but leave active children alive. That may be so, but Timo claimed the opposite (as I read his response). I'm merely pointing out that I cannot see the behavior that Timo states. If you want to get rid of all these processes you have to killall. The behavior is controlled by shutdown_clients setting. I suppose you have it set to no? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v1.1.2 released (managesieve updated)
Timo Sirainen wrote: http://dovecot.org/releases/1.1/dovecot-1.1.2.tar.gz http://dovecot.org/releases/1.1/dovecot-1.1.2.tar.gz.sig I (finally) refreshed the managesieve patch to cleanly apply on the new release: http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.2-managesieve-0.10.3.diff.gz http://www.rename-it.nl/dovecot/1.1/dovecot-1.1.2-managesieve-0.10.3.diff.gz.sig Regards, Stephan
Re: [Dovecot] v1.1.2 released - OK TO INSTALL?
* Bruce Bodger [EMAIL PROTECTED]: Timo, Is this safe to install? The reason that I ask, I read a few reports of problems immediately after your announcement and haven't seen your responses to them. It's giving me less odd warnings in the log than 1.1.1 :) Count that as a yes. -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Like medieval peasants, computer manufacturers and millions of users are locked in a seemingly eternal lease with their evil landlord, who comes around every two years to collect billions of dollars of taxes in return for mediocre services. --Mark Harris, Electronics Times
Re: [Dovecot] Error - Dovecot Permission denied
kbajwa [EMAIL PROTECTED] wrote: Since I posted this original messages, I have installed, re-installed Postfix-2.3.3, Dovecot-1.1.1 Dovecot-Sieve-1.1.5 over and over still got the Permission Denied error (see /var/log/maillog logs below). Here what I found! If I add the following in /etc/postfix/main.cf; Mailbox_command = /usr/libexec/dovecot/deliver Then the Permission Denied error appears and all mail is bounced back with error message. If I remove this line, all emails are delivered fine. No error. [...] (2) what if I leave this line out? Would it cause problem with either Dovecot or Dovecot-Sieve? Unlikely; not setting mailbox_command just means Postfix will use local(8) for mail delivery. [...] Jul 27 09:16:24 www postfix/local[5623]: E31DA41C0028: to=[EMAIL PROTECTED], relay=local, delay=0.99, delays=0.74/0.03/0/0.22, dsn=5.3.5, status=bounced (local configuration error. Command output: Fatal: open(/etc/dovecot.conf) failed: Permission denied ) What are the permissions on /etc/dovecot.conf? The mailbox_command is run with the UID and the primary group GID of the recipient, so if the conf file is unreadable by that user/group, you see the error above. [...] -- Sahil Tandon [EMAIL PROTECTED]
Re: [Dovecot] Error - Dovecot Permission denied
kbajwa wrote: Hello: Since I posted this original messages, I have installed, re-installed Postfix-2.3.3, Dovecot-1.1.1 Dovecot-Sieve-1.1.5 over and over still got the Permission Denied error (see /var/log/maillog logs below). Here what I found! If I add the following in /etc/postfix/main.cf; Mailbox_command = /usr/libexec/dovecot/deliver Then the Permission Denied error appears and all mail is bounced back with error message. If I remove this line, all emails are delivered fine. No error. This problem started when I switched dovecot from Ver# 1.0.7 to 1.1.1 So my question is: (1) has something changed in Dovecot V# 1.1.1 to cause this error? (2) what if I leave this line out? Would it cause problem with either Dovecot or Dovecot-Sieve? if you remove it, mail will be directly delivered by postfix. so no dovecot-sieve for example. (3) Any other solution. FYI, I have already included Postfix, Dovecot Dovecot-Sieve configuration in my previous post. FYI, I have asked for the output of two commands: # ls -l / | grep /etc # ls -l /etc/dovecot.conf in my previous post :) HELP. I have spent 20 days on this problem. if you ignore our posts, you may as well spend another 20 days ;-p
[Dovecot] trace shows imap proceses stuck listing folders
I just moved my mail setup from one machine to a new one. After doing so, I've encountered a problem where imap processes will start accumulating, stuck in a loop eating loads of IO. Below is a trace
[Dovecot] imap processes eating IO
[Ignore the previous e-mail, I somehow sent it when I was trying to
paste from clipboard]
I recently migrated my dovecot/postfix setup to a new machine. After
doing so, I have encountered a problem where imap processes get stuck in
a loop eating loads of IO on the machine. Looking at the trace (snippet
below), it looks like they are sitting and reading the inbox and other
folders of certain users repeatedly. This seems to be triggered by the
delivery of a new e-mail to the user's mailbox while they have an IMAP
client connected, though I cannot say for sure.
This had never happened before on the old machine. I'm certain more
information would be useful, please let me know what I can provide to help!
Trace of process 22342 - imap
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203440140.P6242Q0M41485.scarecrow:2,RSc,
{st_mode=S_IFREG|0600, st_size=3079, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203446630.P7458Q0M562949.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=27769, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203454830.P9042Q0M402016.scarecrow:2,RSe,
{st_mode=S_IFREG|0600, st_size=730534, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203460967.P10096Q0M631472.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=2690, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203463833.P10601Q0M946162.scarecrow:2,Sbc,
{st_mode=S_IFREG|0600, st_size=2319, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203468449.P11425Q0M422185.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=2650, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203469387.P11575Q0M276926.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1317, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203472851.P12516Q0M604824.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=2491, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203474105.P12705Q0M450957.scarecrow:2,RS,
{st_mode=S_IFREG|0600, st_size=1489, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203474330.P12758Q0M302789.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=1483, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203474352.P12765Q0M853382.scarecrow:2,RS,
{st_mode=S_IFREG|0600, st_size=1520, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203475497.P12947Q0M759098.scarecrow:2,RS,
{st_mode=S_IFREG|0600, st_size=1554, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203476420.P13131Q0M140164.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1011, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203477055.P13350Q0M324248.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=1511, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203485834.P14664Q0M678604.scarecrow:2,RSc,
{st_mode=S_IFREG|0600, st_size=2153, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203555290.P27989Q0M937789.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=2017, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203566780.P29789Q0M486178.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1570, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1216416810.P17960Q0M786183.tinman:2,S,
{st_mode=S_IFREG|0600, st_size=1447, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203567387.P29984Q0M463701.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1560, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203568156.P30125Q0M174453.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1570, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203568755.P30222Q0M271021.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1555, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203578404.P31535Q0M370292.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1125, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203581122.P31861Q0M954508.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=2108, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203596470.P3307Q0M326986.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=2738, ...}) = 0
getdents64(12, /* 64 entries */, 4096) = 4096
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203615744.P6582Q0M282341.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=2027, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203619209.P7288Q0M583007.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=8739, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203629165.P9049Q0M921642.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=3049, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203638438.P10774Q0M313047.scarecrow:2,RS,
{st_mode=S_IFREG|0600, st_size=8889, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203639137.P10877Q0M554068.scarecrow:2,S,
{st_mode=S_IFREG|0600, st_size=9549, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203679395.P16427Q0M89616.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=1364, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203689732.P20116Q0M93680.scarecrow:2,Sbc,
{st_mode=S_IFREG|0600,
Re: [Dovecot] imap processes eating IO
On Sun, 2008-07-27 at 12:09 -0500, Ryan Rawdon wrote:
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203440140.P6242Q0M41485.scarecrow:2,RSc,
{st_mode=S_IFREG|0600, st_size=3079, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203446630.P7458Q0M562949.scarecrow:2,Sc,
{st_mode=S_IFREG|0600, st_size=27769, ...}) = 0
You're most likely using dirsize quota backend.
http://wiki.dovecot.org/Quota/Dirsize
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] stopping dovecot
Timo Sirainen wrote on Sun, 27 Jul 2008 17:14:29 +0300: The behavior is controlled by shutdown_clients setting. I suppose you have it set to no? It's set to how dovecot.conf came: #shutdown_clients = yes If that indicates the default it is enabled. But it didn't work. The thread I started wasn't so much about killing these children with a shutdown, anyway. It was about the behavior that these login processes stayed there for more than five hours after a dictionary attack that took only a few minutes before they eventually died away slowly. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: [Dovecot] imap processes eating IO
On Sunday 27 July 2008, Timo Sirainen wrote:
On Sun, 2008-07-27 at 12:09 -0500, Ryan Rawdon wrote:
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203440140.P6242Q0M41485.sc
arecrow:2,RSc, {st_mode=S_IFREG|0600, st_size=3079, ...}) = 0
lstat64(/home/vmail/u13.net/ryan/Maildir/cur/1203446630.P7458Q0M562949.s
carecrow:2,Sc, {st_mode=S_IFREG|0600, st_size=27769, ...}) = 0
You're most likely using dirsize quota backend.
http://wiki.dovecot.org/Quota/Dirsize
That's why I would like to see S= everywhere. Reading dir once tells you
everything and no need to stat() thousands times.
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
Re: [Dovecot] Error - Dovecot Permission denied
Mouss: Here is the information you asked for: [EMAIL PROTECTED] ~]# ls -1 / | grep /etc [EMAIL PROTECTED] ~]# ls -l /etc/dovecot.conf -rw-r- 1 dovecot mail 46723 Jul 26 20:09 /etc/dovecot.conf [EMAIL PROTECTED] ~]# I hope you have an answer. Kirti -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mouss Sent: Sunday, July 27, 2008 10:45 AM Cc: dovecot@dovecot.org Subject: Re: [Dovecot] Error - Dovecot Permission denied FYI, I have asked for the output of two commands: # ls -l / | grep /etc # ls -l /etc/dovecot.conf in my previous post :)
Re: [Dovecot] imap processes eating IO
On Sun, 2008-07-27 at 13:15 -0500, Ryan Rawdon wrote: Timo Sirainen wrote: You're most likely using dirsize quota backend. http://wiki.dovecot.org/Quota/Dirsize I wish it was that simple, but I am currently using maildir++ for quota and did not see this behavior on the previous system which had the same hardware as the new one. What Dovecot version? Did it change during the move? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Error - Dovecot Permission denied
kbajwa [EMAIL PROTECTED] wrote: I have posted the permissions on another post. However, when I look at properties then permissions for 'dovecot.conf' file, following are the 'permissions' listed: Owner:dovecot Access: Read Write Group:Mail Access: Read-Only Others Access: none This is the problem. The mailbox_command runs neither as the dovecot user nor with the mail GID. You need to give others access to read the file. # chmod o+r /etc/dovecot.conf Execute: [] Allow executing file as program SELinux Context: file_t I hope it makes sense to you, it does not to me. Let me know if the above need some change. [...] -- Sahil Tandon [EMAIL PROTECTED]
Re: [Dovecot] Error - Dovecot Permission denied
On Sat, 2008-07-26 at 10:06 -0600, kbajwa wrote: (2) status=bounced (local configuration error. Command output: Fatal: open(/etc/dovecot.conf) failed: Permission denied ) So you're using multiple UIDs for users? Possible solutions: a) Make dovecot.conf world-readable (Is there really something secret in it? ssl_key_password is the only one I can think of.) b) Use virtual users with a single UID and make dovecot.conf owned by that UID. c) Make deliver setgid-mail and change dovecot.conf group to mail. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] mail extra field to override default mail_location for only certain users
Nevermind, I found the solution. For those of you following along at home: http://wiki.dovecot.org/AuthDatabase/PasswdFile user:password:uid:gid:(gecos):home:(shell):extra_fields is correct. -- Sahil Tandon [EMAIL PROTECTED]
Re: [Dovecot] Error - Dovecot Permission denied
Big thanks. It worked. Kirti -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sahil Tandon Sent: Sunday, July 27, 2008 1:53 PM To: kbajwa Cc: dovecot@dovecot.org Subject: Re: [Dovecot] Error - Dovecot Permission denied kbajwa [EMAIL PROTECTED] wrote: I have posted the permissions on another post. However, when I look at properties then permissions for 'dovecot.conf' file, following are the 'permissions' listed: Owner:dovecot Access: Read Write Group:Mail Access: Read-Only Others Access: none This is the problem. The mailbox_command runs neither as the dovecot user nor with the mail GID. You need to give others access to read the file. # chmod o+r /etc/dovecot.conf Execute: [] Allow executing file as program SELinux Context: file_t I hope it makes sense to you, it does not to me. Let me know if the above need some change. [...] -- Sahil Tandon [EMAIL PROTECTED]
Re: [Dovecot] v1.1.2 released - OK TO INSTALL?
On Jul 27, 2008, at 12:41 PM, Ralf Hildebrandt wrote: * Bruce Bodger [EMAIL PROTECTED]: Timo, Is this safe to install? The reason that I ask, I read a few reports of problems immediately after your announcement and haven't seen your responses to them. It's giving me less odd warnings in the log than 1.1.1 :) Count that as a yes. Took your advice, Ralf. All is well so far. Running on OS X 10.4.11 Thank you.
[Dovecot] odd pam_authenticate() failed: authentication error followed by successful imap-login
I am seeing the following errors in my log: Jul 27 18:14:23 aegis dovecot: auth-worker(default_with_listener): pam([EMAIL PROTECTED],74.72.46.170): pam_authenticate() failed: authentication error Jul 27 18:14:23 aegis dovecot: imap-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=74.72.46.170, lip=206.251.255.39, TLS This happens *only* for virtual users; local UNIX users authenticate without that first error. However, all users are able to view mail, but that default_with_listener (which I setup just so Postfix could use dovecot to authenticate SASL senders) error only occurs for virtual users. Why is default_with_listener getting involved when users are trying to connect to dovecot directly without any involvement of Postfix? Non-default configuration parameters below; thanks for any hints. # dovecot -n # 1.1.1: /usr/local/etc/dovecot.conf listen: 127.0.0.1:143 ssl_listen: *:993 login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login verbose_proctitle: yes first_valid_gid: 0 mail_privileged_group: mail mail_location: maildir:~/Maildir imap_client_workarounds: delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep auth default_with_listener: mechanisms: plain login digest-md5 passdb: driver: pam passdb: driver: passwd-file args: /usr/local/etc/dovecot/passwd userdb: driver: passwd userdb: driver: passwd-file args: /usr/local/etc/dovecot/users socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix auth default: mechanisms: plain digest-md5 passdb: driver: passwd-file args: /usr/local/etc/dovecot/passwd passdb: driver: pam userdb: driver: passwd-file args: /usr/local/etc/dovecot/users userdb: driver: passwd -- Sahil Tandon [EMAIL PROTECTED]
[Dovecot] dovecot.sieve file location?
CentOS 5.2 Postfix-2.3.3 Dovecot-1.1.1 Dovecot.Sieve-1.1.5 I have setup with: home_mailbox = Maildir/ (/etc/postfix/main.cf) mail-location = maildir:~/Maildir (/etc/dovecot.conf) I have created a 'test' user to test Sieve 'Vacation' setup. My questions are: 1. Which folder '.dovecot.sieve' script is copied into? Is it 'home/test' -or- 'home/test/Maildir' or someplace else? 2. '.dovecot.sieve' script parameter :days 1 means that the reply is sent once a day. Is it possible to send the reply 'immediately'? Kirti
[Dovecot] dovecot.sieve file location?
CentOS 5.2 Postfix-2.3.3 Dovecot-1.1.1 Dovecot.Sieve-1.1.5 I have setup with: home_mailbox = Maildir/ (/etc/postfix/main.cf) mail-location = maildir:~/Maildir (/etc/dovecot.conf) I have created a 'test' user to test Sieve 'Vacation' setup. My questions are: 1. Which folder '.dovecot.sieve' script is copied into? Is it 'home/test' -or- 'home/test/Maildir' or someplace else? 2. '.dovecot.sieve' script parameter :days 1 means that the reply is sent once a day. Is it possible to send the reply 'immediately'? Kirti
Re: [Dovecot] odd pam_authenticate() failed: authentication error followed by successful imap-login [solved]
Sahil Tandon [EMAIL PROTECTED] wrote: I am seeing the following errors in my log: Jul 27 18:14:23 aegis dovecot: auth-worker(default_with_listener): pam([EMAIL PROTECTED],74.72.46.170): pam_authenticate() failed: authentication error Jul 27 18:14:23 aegis dovecot: imap-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=74.72.46.170, lip=206.251.255.39, TLS [...] # dovecot -n # 1.1.1: /usr/local/etc/dovecot.conf listen: 127.0.0.1:143 ssl_listen: *:993 login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login verbose_proctitle: yes first_valid_gid: 0 mail_privileged_group: mail mail_location: maildir:~/Maildir imap_client_workarounds: delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep auth default_with_listener: mechanisms: plain login digest-md5 passdb: driver: pam passdb: driver: passwd-file args: /usr/local/etc/dovecot/passwd I guess order matters. Once I set the virtual user database to be queried before pam, the error is gone. Are there any side effects which I might not be considering? Thanks. [...] -- Sahil Tandon [EMAIL PROTECTED]
Re: [Dovecot] imap processes eating IO
Timo Sirainen wrote: On Sun, 2008-07-27 at 13:15 -0500, Ryan Rawdon wrote: Timo Sirainen wrote: You're most likely using dirsize quota backend. http://wiki.dovecot.org/Quota/Dirsize I wish it was that simple, but I am currently using maildir++ for quota and did not see this behavior on the previous system which had the same hardware as the new one. What Dovecot version? Did it change during the move? Yes, 1.0.5 -- 1.0.10
