[Dovecot] 1.0.alpha4 process creation wierdness
Hi list!
I'm a little confused. I have set "login_process_per_connection = yes" and "login_processes_count = 1", and this is how my pstree looks when nobody is connected:
dovecot -,- dovecot-auth
`- imap-login
However, when I connect with a client it looks like this:
dovecot -,- dovecot-auth
|- imap
`- 2*[imap-login]
I would expect it to only have one imap-login running. Anyway, when I disconnect the client, the imap process exits but imap-login keeps running:
dovecot -,- dovecot-auth
`- 2*[imap-login]
This is when it gets really wierd. When I connect a client again, my pstree looks like I would have expected it to on my first connect:
dovecot -,- dovecot-auth
|- imap
`- imap-login
If I re-connect, we start over again (i.e. dovecot-auth, imap, 2 * imap-login). Anybody got a clue what's going on? :-)
--
.-. Mark Rosenstand (-.)
oo| cc )
/'\ (+45) 255 31337 3-n-( (\_;/) mark@borkware.net _(|/
->
On Sun, 2005-10-23 at 08:11 +0200, Mark Rosenstand wrote:
Hi list!
I'm a little confused. I have set "login_process_per_connection = yes" and "login_processes_count = 1", and this is how my pstree looks when nobody is connected:
dovecot -,- dovecot-auth `- imap-login
However, when I connect with a client it looks like this:
dovecot -,- dovecot-auth |- imap `- 2*[imap-login]
I would expect it to only have one imap-login running.
No. login_process_per_connection means that each incoming connection gets its own imap-login process. If the user happens to be using TLS/SSL, then the imap-login process doesn't die until the connection closes (since it's proxying the SSL connection).
Also login_process_count doesn't actually mean the maximum number of imap-login processes that can be waiting.. It's rather the minimum number of processes to use while everything is idling.
The actual rules go like this:
/* we want to respond fast when multiple clients are connecting
at once, but we also want to prevent fork-bombing. use the
same method as apache: check once a second if we need new
processes. if yes and we've used all the existing processes,
double their amount (unless we've hit the high limit).
Then for each second that didn't use all existing processes,
drop the max. process count by one. */
if (group->wanted_processes_count < group->set->login_processes_count) {
group->wanted_processes_count =
group->set->login_processes_count;
} else if (group->listening_processes == 0)
group->wanted_processes_count *= 2;
else if (group->wanted_processes_count >
group->set->login_processes_count)
group->wanted_processes_count--;
if (group->wanted_processes_count >
group->set->login_max_processes_count) {
group->wanted_processes_count =
group->set->login_max_processes_count;
}
In Dovecot 2.0 there will be a rewritten master process and its process creation rules are probably more easily understandable..
Timo Sirainen wrote:
I would expect it to only have one imap-login running.
If the user happens to be using TLS/SSL, then the imap-login process doesn't die until the connection closes (since it's proxying the SSL connection).
I wasn't aware that it worked that way, thanks for explaining!
In Dovecot 2.0 there will be a rewritten master process and its process creation rules are probably more easily understandable..
Please don't mention Dovecot 2.0 again before there are previews available; I accidently started drooling on my keyboard...
--
.-. Mark Rosenstand (-.)
oo| cc )
/'\ (+45) 255 31337 3-n-( (\_;/) mark@borkware.net _(|/
->
On Tue, 2005-12-06 at 17:28 +0100, Mark Rosenstand wrote:
In Dovecot 2.0 there will be a rewritten master process and its process creation rules are probably more easily understandable..
Please don't mention Dovecot 2.0 again before there are previews available; I accidently started drooling on my keyboard...
Actually there is already :) Originally I thought I'd make this rewrite already for v1.0, but then decided to leave it for v2.0. There's nothing else there than master/config/log process rewrite though.
http://dovecot.org/tmp/dovecot-1.0-test67-mrewrite.tar.gz
Probably doesn't work too well, and only docs available are somewhere in this mailing list's archives.
participants (2)
-
Mark Rosenstand
-
Timo Sirainen