Hi!I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql {
iterate_query = SELECT email AS user FROM users
}
In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
Bogusław JuzaHi!
I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql { iterate_query = SELECT
userFROMusers}In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
I had the same problem with doveadm -A commands after upgrading from Debian 12 to Debian 13 including dovecot upgrade from 2.3.19 to 2.4.1.
My current theory is that changes in how SQL is integrated in 2.4 are causing the iterate query session to time out during something you do with doveadm and -A option and a larger amout of users.
I wrote about this last week, you can find it under the title "doveadm backup / purge problems since migration from 2.3 to 2.4".
My current workarround is a script that generates a user list via doveadm user '*' , cached this and then execute the doveadm command you need for each user in this list. Works for me with arround 4k user.
Since this is the second time I heard of that is here anyone else who had the same problem? I thought it might be a problem on my end, but it seems to be an issue with Dovecot 2.4 since I'm clearly not the only one who is affected. Maybe someone from the dovecot Team has heared about it? Would be nice if this can be fixed and I can use -A option since before.
Oliver
On 17/07/2026 16:23, MK via dovecot wrote:
Hi!
I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql { iterate_query = SELECT
userFROMusers}In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
I had the same problem with
doveadm -Acommands after upgrading from Debian 12 to Debian 13 including dovecot upgrade from 2.3.19 to 2.4.1. My current theory is that changes in how SQL is integrated in 2.4 are causing the iterate query session to time out during something you do with doveadm and -A option and a larger amout of users. I wrote about this last week, you can find it under the title "doveadm backup / purge problems since migration from 2.3 to 2.4". My current workarround is a script that generates a user list via doveadm user '*' , cached this and then execute the doveadm command you need for each user in this list. Works for me with arround 4k user.Since this is the second time I heard of that is here anyone else who had the same problem? I thought it might be a problem on my end, but it seems to be an issue with Dovecot 2.4 since I'm clearly not the only one who is affected. Maybe someone from the dovecot Team has heared about it? Would be nice if this can be fixed and I can use -A option since before.
Oliver
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John
Hi!
I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql { iterate_query = SELECT
userFROMusers}In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
I had the same problem with
doveadm -Acommands after upgrading from Debian 12 to Debian 13 including dovecot upgrade from 2.3.19 to 2.4.1. My current theory is that changes in how SQL is integrated in 2.4 are causing the iterate query session to time out during something you do > with doveadm and -A option and a larger amout of users. I wrote about this last week, you can find it under the title "doveadm backup / purge problems since migration from 2.3 to 2.4". My current workarround is a script that generates a user list via doveadm user '*' , cached this and then execute the doveadm command you need > for each user in this list. Works for me with arround 4k user.Since this is the second time I heard of that is here anyone else who had the same problem? I thought it might be a problem on my end, but it seems to be an issue with Dovecot 2.4 since I'm clearly not the only one who is affected. Maybe someone from the dovecot Team has heared about it? Would be nice if this can be fixed and I can use -A option since before.
Oliver
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John
Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
On 20/07/2026 11:38, MK via dovecot wrote:
Hi!
I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql { iterate_query = SELECT
userFROMusers}In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
I had the same problem with
doveadm -Acommands after upgrading from Debian 12 to Debian 13 including dovecot upgrade from 2.3.19 to 2.4.1. My current theory is that changes in how SQL is integrated in 2.4 are causing the iterate query session to time out during something you do > with doveadm and -A option and a larger amout of users. I wrote about this last week, you can find it under the title "doveadm backup / purge problems since migration from 2.3 to 2.4". My current workarround is a script that generates a user list via doveadm user '*' , cached this and then execute the doveadm command you need > for each user in this list. Works for me with arround 4k user.Since this is the second time I heard of that is here anyone else who had the same problem? I thought it might be a problem on my end, but it seems to be an issue with Dovecot 2.4 since I'm clearly not the only one who is affected. Maybe someone from the dovecot Team has heared about it? Would be nice if this can be fixed and I can use -A option since before.
Oliver
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
Hi Oliver
so far I haven't seen any follow up from the development team.
In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user.
John
Hi!
I have a problem with Dovecot on Debian 13:
Dovecot 2.4.1, Debian Trixie
doveadm mailbox path -A INBOX >/dev/null doveadm(email@domain): Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd mailbox path: Failed to iterate through some users
userdb sql { iterate_query = SELECT
userFROMusers}In syslog file: dovecot: auth: Error: auth-worker: Aborted LIST request for *: Shutting down
I have over 30k users in sql DB, doveadm with -A option is dying few second after start with this error, printing about 10% of users. I need much more time (FE command "doveadm expunge -A mailbox Spam savedbefore 3w" could run over 30 minutes).
What I'm doing wrong?
I had the same problem with
doveadm -Acommands after upgrading from Debian 12 to Debian 13 including dovecot upgrade from 2.3.19 to 2.4.1. My current theory is that changes in how SQL is integrated in 2.4 are causing the iterate query session to time out during something you do > >with doveadm and -A option and a larger amout of users. I wrote about this last week, you can find it under the title "doveadm backup / purge problems since migration from 2.3 to 2.4". My current workarround is a script that generates a user list via doveadm user '*' , cached this and then execute the doveadm command you >need > for each user in this list. Works for me with arround 4k user.Since this is the second time I heard of that is here anyone else who had the same problem? I thought it might be a problem on my end, but it seems to be an issue with Dovecot 2.4 since I'm clearly not the only one who is affected. Maybe someone from the dovecot Team has heared about it? Would be nice if this can be fixed and I can use -A option since before.
Oliver
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it.
In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
On 20/07/2026 16:53, MK via dovecot wrote:
[snip]
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
__________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment.
In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active. John diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, }; static int
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
[snip]
Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
__________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment.
In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix. Aki
On 24/07/2026 08:13 EEST Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
> [snip] > Hi
it appears to be a bug in dovecot 2.4.x when iterating thousands of users.
See https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ...
The fix I posted there did bypass the issue during a test I did. I am not sure it could be treated as a definitive fix. Another workaround is to iterate outside dovecot.
John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
__________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment.
In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix.
Aki
This bug is already fixed in 2.4.3 with https://github.com/dovecot/core/compare/41b244c9%5E...d4362583.patch Aki
On 24/07/2026 08:13, Aki Tuomi via dovecot wrote:
On 24/07/2026 08:13 EEST Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
>> [snip] >> > Hi > > it appears to be a bug in dovecot 2.4.x when iterating thousands of users. > > See > https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ... > > The fix I posted there did bypass the issue during a test I did. I am > not sure it could be treated as a definitive fix. Another workaround is > to iterate outside dovecot. > > John Hi,
did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user)
Oliver
__________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment. In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix.
Aki
This bug is already fixed in 2.4.3 with https://github.com/dovecot/core/compare/41b244c9%5E...d4362583.patch
Aki
Thanks Aki you're right it is solved in 2.4.3. That surprised me since I was still seeing iterate errors on 2.4.4. and I wrongly assumed it was due to the same cause. Looking into it I am now sometimes hitting a timeout of 155 seconds. This is with 20K users configured. It takes approx 140 secs for "doveadm quota get -A" with users in mysql, but turning on the debugging tends to bring it over the 155 second limit. I guess that with 30K users I'd be always hitting the timeout. Seems each user iteration is taking a bit longer in 2.4.4 than on 2.4.1. If I get time I'll see if I can put some concrete numbers around the difference. John
w
On 24/07/2026 14:46 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 24/07/2026 08:13, Aki Tuomi via dovecot wrote:
On 24/07/2026 08:13 EEST Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
>>> [snip] >>> >> Hi >> >> it appears to be a bug in dovecot 2.4.x when iterating thousands of users. >> >> See >> https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ... >> >> The fix I posted there did bypass the issue during a test I did. I am >> not sure it could be treated as a definitive fix. Another workaround is >> to iterate outside dovecot. >> >> John > Hi, > > did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. > So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. > Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user) > > Oliver > > > __________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment. In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix.
Aki
This bug is already fixed in 2.4.3 with https://github.com/dovecot/core/compare/41b244c9%5E...d4362583.patch
Aki
Thanks Aki
you're right it is solved in 2.4.3. That surprised me since I was still seeing iterate errors on 2.4.4. and I wrongly assumed it was due to the same cause. Looking into it I am now sometimes hitting a timeout of 155 seconds. This is with 20K users configured. It takes approx 140 secs for "doveadm quota get -A" with users in mysql, but turning on the debugging tends to bring it over the 155 second limit. I guess that with 30K users I'd be always hitting the timeout.
Seems each user iteration is taking a bit longer in 2.4.4 than on 2.4.1. If I get time I'll see if I can put some concrete numbers around the difference.
John
Can you send us logs and such? Aki
On 24/07/2026 13:57, Aki Tuomi via dovecot wrote:
w
On 24/07/2026 14:46 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 24/07/2026 08:13, Aki Tuomi via dovecot wrote:
On 24/07/2026 08:13 EEST Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
>>>> [snip] >>>> >>> Hi >>> >>> it appears to be a bug in dovecot 2.4.x when iterating thousands of users. >>> >>> See >>> https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ... >>> >>> The fix I posted there did bypass the issue during a test I did. I am >>> not sure it could be treated as a definitive fix. Another workaround is >>> to iterate outside dovecot. >>> >>> John >> Hi, >> >> did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. >> So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. >> Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user) >> >> Oliver >> >> >> __________ > Hi Oliver > > so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment. > In my experience doveadm user '*' also runs into the same trouble for > large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
> Where the users are in a mysql database, you could query the db directly > to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix.
Aki
This bug is already fixed in 2.4.3 with https://github.com/dovecot/core/compare/41b244c9%5E...d4362583.patch
Aki
Thanks Aki
you're right it is solved in 2.4.3. That surprised me since I was still seeing iterate errors on 2.4.4. and I wrongly assumed it was due to the same cause. Looking into it I am now sometimes hitting a timeout of 155 seconds. This is with 20K users configured. It takes approx 140 secs for "doveadm quota get -A" with users in mysql, but turning on the debugging tends to bring it over the 155 second limit. I guess that with 30K users I'd be always hitting the timeout.
Seems each user iteration is taking a bit longer in 2.4.4 than on 2.4.1. If I get time I'll see if I can put some concrete numbers around the difference.
John Can you send us logs and such?
Aki
_________________
Hi so here's some more concrete data. The environment is the same one, the database is the same and the file system is the same across all tests. The command was "doveadm -Dv quota get -A" with 20000 users to iterate through. Given the size I'll send the log files off list to Aki, unless someone else is interested in seeing them. Summarizing the results, on 2.4.1 the command got the "Failed to iterate" error that has now been fixed, but averaged around 5.9 msecs/user on the users that were processed. When patched with my original patch, the performance was similar, average 5.2msecs/user and managing to complete all users. On 2.4.4 average time has increased to 9.6 msecs/user and can now run into "Failed to iterate" due to timeout of 155 seconds. The environment itself is a small sandbox, but it should be good for comparisons. On 2.4.1 the error output was: Error: auth-master: userdb list: User listing returned failure doveadm: Error: cmd quota get: Failed to iterate through some users Time taken approx 14 seconds for 2040 users, average of 5.9 msecs per user, ranging from 3.8 msecs - 41.7 msecs On 2.4.1 with my original patch the output had no errors: Time taken approx 103 seconds for 20000 users, average of 5.2 msecs per user, ranging from 3.8 msecs - 13.5 msecs On 2.4.4 the error output was: Error: auth-master: userdb list: User listing failed: Auth server request timed out after 155.116 secs doveadm: Error: cmd quota get: Failed to iterate through some users Time taken approx 155 seconds for 16099 users, average of 9.6 msecs per user, ranging from 5.6 msecs - 23.8 msecs I have also found other commands that easily timeout like doveadm force-resync -A INBOX. When splitting into two steps "doveadm user '*' > file" and "doveadm force-resync -F file INBOX" it took around 6 minutes, but didn't hit the timeout which in the case of reading from file is applied to the single users not to the whole transaction. John
"John" == John Fawcett via dovecot <dovecot@dovecot.org> writes:
On 24/07/2026 08:13, Aki Tuomi via dovecot wrote:
On 24/07/2026 08:13 EEST Aki Tuomi via dovecot <dovecot@dovecot.org> wrote:
On 21/07/2026 01:00 EEST John Fawcett via dovecot <dovecot@dovecot.org> wrote:
On 20/07/2026 16:53, MK via dovecot wrote:
>>> [snip] >>> >> Hi >> >> it appears to be a bug in dovecot 2.4.x when iterating thousands of users. >> >> See >> https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/message/P5QBZ... >> >> The fix I posted there did bypass the issue during a test I did. I am >> not sure it could be treated as a definitive fix. Another workaround is >> to iterate outside dovecot. >> >> John > Hi, > > did you get a feedback from someone of the dovecot developer? Since your request is 4 month ago. > So this sounds like my used workarround seem to be the best we can do at the moment, as Philip did the same. > Do you have experiences if this works with about 40k users or more too? (doveadm user '*', cache this and then execute doveadm -u for each user) > > Oliver > > > __________ Hi Oliver
so far I haven't seen any follow up from the development team. It's bad that no one is taking care of it. I guess it is not one of the high priority issues at the moment. In my experience doveadm user '*' also runs into the same trouble for large numbers of users. I got issues with even 20K users on 2.4.x. At the moment I'm using it for ~ 4400 user and have no problems. I'm curious to see how it works with 40k users.
Where the users are in a mysql database, you could query the db directly to get the usernames and then execute doveadm -u for each user. Sure, that's an option if the doveadm iterate did not work for that mutch user.
Thanks Oliver
Hi all
this is a revised fix. This looks like the minimal fix. The alternative is to refactor the auth-master-connection code to make it compatible with the 2.4 throttling logic. Setting output_throttle_size to zero will then just use the same throttling mechanism as there was in 2.3.21, which is still present in 2.4 for this code path. The problem arises when both mechanisms are active.
John
diff -u dovecot-2.4.4/src/auth/auth-master-connection.c.orig dovecot-2.4.4/src/auth/auth-master-connection.c --- dovecot-2.4.4/src/auth/auth-master-connection.c.orig 2026-07-20 22:55:09.153747336 +0200 +++ dovecot-2.4.4/src/auth/auth-master-connection.c 2026-07-20 22:55:32.423163048 +0200 @@ -740,7 +740,7 @@ .dont_send_version = TRUE, .input_max_size = MAX_INBUF_SIZE, .output_max_size = SIZE_MAX, - .output_throttle_size = MAX_OUTBUF_SIZE, + .output_throttle_size = 0, };
static int
Sorry for missing on this, we'll take a look at the problem and the proposed fix.
Aki
This bug is already fixed in 2.4.3 with https://github.com/dovecot/core/compare/41b244c9%5E...d4362583.patch
Aki
Thanks Aki
you're right it is solved in 2.4.3. That surprised me since I was still seeing iterate errors on 2.4.4. and I wrongly assumed it was due to the same cause. Looking into it I am now sometimes hitting a timeout of 155 seconds. This is with 20K users configured. It takes approx 140 secs for "doveadm quota get -A" with users in mysql, but turning on the debugging tends to bring it over the 155 second limit. I guess that with 30K users I'd be always hitting the timeout.
I'm curious, is the loss in speed because the quota is recalculated for each user when this is run? Or is your mysql query just slow? If it's the first, I wonder if there is a way to optmize things by keeping a quota cache in memory for the most recent users, and for those inactive users, just keep it in a mysql table so you're not scanning the disk all the time to recalculate. But of course I don't know how this all works. I'm just thinking that 20k records in mysql should be pretty damn quick to return honestly.
Seems each user iteration is taking a bit longer in 2.4.4 than on 2.4.1. If I get time I'll see if I can put some concrete numbers around the difference.
participants (5)
-
Aki Tuomi
-
Bogusław Juza
-
John Fawcett
-
John Stoffel
-
MK