With 1.0.15 my configuration I a single dovecot-auth process, which is what I want now. Since upgrading to 1.2.10 I have two such processes:
root 16992 16990 0 Feb15 ? 00:00:00 dovecot-auth root 16997 16990 0 Feb15 ? 00:00:00 dovecot-auth -w
I can't seem to tweak dovecot.conf to get this down to one auth process again. I've tried setting each of these below to 0, which resulted in either none, or one auth process. In the case of the one auth process, T-Bird wasn't working correctly, although it presented no pop up or other errors. When I'd click an IMAP folder it would just show whitespace and never pull up the emails.
auth_worker_max_count =
# Number of authentication processes to create count =
This is an extremely low volume host, and I'm an efficiency freak. I don't like having "unnecessary" processes running if it is at all possible to avoid it. Given my IMAP user load, I know for a fact that I should only need one auth process, and for that matter, given my load, running all the dovecot processes from inetd is even a valid option, although I've not yet attempted that.
Any ideas?
Thanks.
-- Stan
On Tue, 2010-02-16 at 08:16 -0600, Stan Hoeppner wrote:
With 1.0.15 my configuration I a single dovecot-auth process, which is what I want now. Since upgrading to 1.2.10 I have two such processes:
root 16992 16990 0 Feb15 ? 00:00:00 dovecot-auth root 16997 16990 0 Feb15 ? 00:00:00 dovecot-auth -w
I can't seem to tweak dovecot.conf to get this down to one auth process again.
Are you using passwd/pam combination? The second process is "auth worker", which does blocking passdb/userdb lookups. The v1.0 behavior was causing bugs.
Given my IMAP user load, I know for a fact that I should only need one auth process, and for that matter, given my load,
Currently there's no way to avoid that, except if you switch from PAM to e.g. shadow. v2.0 stops idling processes after a minute (but there are a some other new long running processes, and also it looks like that idle-stopping isn't currently working for some reason).
running all the dovecot processes from inetd is even a valid option, although I've not yet attempted that.
That won't help anyway. You'd still have the same processes.
Timo Sirainen put forth on 2/18/2010 9:17 AM:
On Tue, 2010-02-16 at 08:16 -0600, Stan Hoeppner wrote:
With 1.0.15 my configuration I a single dovecot-auth process, which is what I want now. Since upgrading to 1.2.10 I have two such processes:
root 16992 16990 0 Feb15 ? 00:00:00 dovecot-auth root 16997 16990 0 Feb15 ? 00:00:00 dovecot-auth -w
I can't seem to tweak dovecot.conf to get this down to one auth process again.
Are you using passwd/pam combination? The second process is "auth worker", which does blocking passdb/userdb lookups. The v1.0 behavior was causing bugs.
Yep: auth default: worker_max_count: 1 process_size: 16 passdb: driver: pam userdb: driver: passwd
If this is what the worker does, what does the "master" do?
Currently there's no way to avoid that, except if you switch from PAM to e.g. shadow. v2.0 stops idling processes after a minute (but there are a some other new long running processes, and also it looks like that idle-stopping isn't currently working for some reason).
IIRC both dovecot-auth processes are staying resident even with no clients connected.
running all the dovecot processes from inetd is even a valid option, although I've not yet attempted that.
That won't help anyway. You'd still have the same processes.
It's not that big a deal. I just didn't realize this had changed since 1.0.15, so I thought I just needed to tweak something to ditch the extra process. If both auth processes are required for pam/passwd to function correctly in 1.2.10 then that's fine by me.
Thanks Timo.
-- Stan
On Thu, 2010-02-18 at 12:47 -0600, Stan Hoeppner wrote:
Are you using passwd/pam combination? The second process is "auth worker", which does blocking passdb/userdb lookups. The v1.0 behavior was causing bugs.
Yep: auth default: worker_max_count: 1 process_size: 16 passdb: driver: pam userdb: driver: passwd
If this is what the worker does, what does the "master" do?
With v1.0 each PAM lookup caused dovecot-auth to fork a new process, which then did the PAM stuff and then exited. With v1.1+ the auth worker process does this so that there's no need for the forking (that caused problems with some nss/pam combinations).
So dovecot-auth master gets the actual auth requests and starts handling them. When it needs to do a blocking passdb/userdb lookup, it connects to auth worker, which then does the actual (potentially long running) lookup. If you've enough load, more auth worker processes are created as necessary.
Hmm. You could try setting auth_worker_max_request_count=1 to see if that gets rid of the processes after they've handled the request.
Currently there's no way to avoid that, except if you switch from PAM to e.g. shadow. v2.0 stops idling processes after a minute (but there are a some other new long running processes, and also it looks like that idle-stopping isn't currently working for some reason).
IIRC both dovecot-auth processes are staying resident even with no clients connected.
Yes, only v2.0 has the idle-stopping feature.
Timo Sirainen put forth on 2/18/2010 12:54 PM:
Hmm. You could try setting auth_worker_max_request_count=1 to see if that gets rid of the processes after they've handled the request.
Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 1: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf
FYI I'm running 1.2.10
-- Stan
Quoting Stan Hoeppner stan@hardwarefreak.com:
Timo Sirainen put forth on 2/18/2010 12:54 PM:
Hmm. You could try setting auth_worker_max_request_count=1 to see if that gets rid of the processes after they've handled the request.
Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 1: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf
FYI I'm running 1.2.10
-- Stan
Could be a typo, could be your problem, but:
auth_worker_max_request_count != worker_max_request_count
(i.e., did you forget the "auth_" at the start?)
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
Eric Rostetter put forth on 2/18/2010 3:21 PM:
Quoting Stan Hoeppner stan@hardwarefreak.com:
Timo Sirainen put forth on 2/18/2010 12:54 PM:
Hmm. You could try setting auth_worker_max_request_count=1 to see if that gets rid of the processes after they've handled the request.
Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 1: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf
FYI I'm running 1.2.10
-- Stan
Could be a typo, could be your problem, but:
auth_worker_max_request_count != worker_max_request_count
(i.e., did you forget the "auth_" at the start?)
I think it's sad that sometimes some sysadmins assume their fellow sysadmins are less than capable, to put it politely.
[02:55:20][root@greer]/home/stan$ dovecot -a|grep auth_worker_max_request_count [02:55:26][root@greer]/home/stan$ man dovecot [02:56:36][root@greer]/home/stan$ man dovecot.conf No manual entry for dovecot.conf [02:56:40][root@greer]/home/stan$ vi /etc/dovecot/dovecot.conf [03:02:06][root@greer]/home/stan$ dovecot restart Usage: dovecot [-F] [-c <config file>] [-p] [-n] [-a] [--version] [--build-options] [--exec-mail <protocol> [<args>]] Fatal: Unknown argument: restart [03:02:11][root@greer]/home/stan$ /etc/init.d/dovecot Usage: /etc/init.d/dovecot {start|stop|restart|force-reload|status} [03:02:41][root@greer]/home/stan$ /etc/init.d/dovecot status dovecot is running. [03:03:10][root@greer]/home/stan$ /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 868: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf failed! [03:04:33][root@greer]/home/stan$ vi /etc/dovecot/dovecot.conf [03:06:09][root@greer]/home/stan$ /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 1: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf failed! [03:06:50][root@greer]/home/stan$ vi /etc/dovecot/dovecot.conf [03:07:38][root@greer]/home/stan$ /etc/init.d/dovecot restart Restarting IMAP/POP3 mail server: dovecot.
Now, does that string of actions look to you like I fucked up, didn't verify my edits and results, before reporting back? Pristine? No. Perfect? No. _Thorough_? YES.
Dovecot strips the "auth_" portion of the parameter name in that error message. I don't know why. Do you? If you're running 1.2.10 or prior on one of your systems, insert that parameter into dovecot.conf, do a restart or force reload, and report back the error message, if any, that you receive.
Maybe then you might have a constructive, positive comment for me.
-- Stan
On 18.2.2010, at 23.08, Stan Hoeppner wrote:
Timo Sirainen put forth on 2/18/2010 12:54 PM:
Hmm. You could try setting auth_worker_max_request_count=1 to see if that gets rid of the processes after they've handled the request.
Restarting IMAP/POP3 mail server: dovecotError: Error in configuration file /etc/dovecot/dovecot.conf line 1: Unknown setting: worker_max_request_count Fatal: Invalid configuration in /etc/dovecot/dovecot.conf
FYI I'm running 1.2.10
Oh, right, it changed in v1.2 to:
passdb pam { args = max_requests=1 }
participants (3)
-
Eric Rostetter
-
Stan Hoeppner
-
Timo Sirainen