[Dovecot] more than 200 imap processes for one user
HI, recently I noticed, that our dovecot server (RH EL 5.7 dovecot-1.0.7-7.el5_7.1) 'fires' up a lot of imap processes only for one user. I counted 214 :-) most of tham in the 'S' state and are started nearly at the same time within 5 minutes. Usually users do have about 4 to 10 Dose anyone has an idea, what could be the cause? Thanks for any suggestion and 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 Vorsitzender des Aufsichtsrats: Jürgen Walter MdL Staatssekretär im Ministerium für Wissenschaft, Forschung und Kunst Baden-Württemberg Geschäftsführer: Prof. Thomas Schadt smime.p7s Description: S/MIME Kryptografische Unterschrift
Re: [Dovecot] MySQL server has gone away
On 13.1.2012, at 4.00, Mark Moseley wrote:
I'm running 2.0.17 and I'm still seeing a decent amount of MySQL
server has gone away errors, despite having multiple hosts defined in
my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
the same thing with 2.0.16 on Debian Squeeze 64-bit.
E.g.:
Jan 12 20:30:33 auth-worker: Error: mysql: Query failed, retrying:
MySQL server has gone away
Our mail mysql servers are busy enough that wait_timeout is set to a
whopping 30 seconds. On my regular boxes, I see a good deal of these
in the logs. I've been doing a lot of mucking with doveadm/dsync
(working on maildir-mdbox migration finally, yay!) on test boxes
(same dovecot package version) and when I get this error, despite
the log saying it's retrying, it doesn't seem to be. Instead I get:
dsync(root): Error: user ...: Auth USER lookup failed
Try with only one host in the connect string? My guess: Both the connections
have timed out, and the retrying fails as well (there is only one retry).
Although if the retrying lookup fails, there should be an error logged about it
also (you don't see one?)
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
Re: [Dovecot] more than 200 imap processes for one user
On 13.1.2012, at 11.01, Götz Reinicke wrote: recently I noticed, that our dovecot server (RH EL 5.7 dovecot-1.0.7-7.el5_7.1) 'fires' up a lot of imap processes only for one user. v1.1+ limits this to 10 processes by default. Dose anyone has an idea, what could be the cause? Some client gone crazy.
[Dovecot] dsync conversion and ldap attributes
I have:
mail_home = /srv/mailstore/%256RHu/%d/%n
mail_location = maildir:~/:INDEX=/indexes/%1u/%1.1u/%u
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
and the dovecot-ldap.conf.ext specifies:
user_attrs = mailMessageStore=home, mailLocation=mail,
mailQuota=quota_rule=*:storage=%$
Now I want to convert individual users to mdbox using dsync, but how to
I tell location2 to not fetch home and mail from ldap and use
different mail_location (mdbox:~/mdbox) ? I.e. I want converted accounts stored
in
mail_location mdbox:/srv/mailstore/%256RHu/%d/%n/mdbox.
-jf
Re: [Dovecot] Need help with details for new Dovecot plugin
On 2012-01-12 6:10 PM, Maarten Bezemer mcbdove...@robuust.nl wrote: Of course I don't know anything about the details of the project (number of users, requirements for speed of MWI updates, mail storage type, etc.) but if it's not a very large setup and mail storage is mbox or maildir, I'd probably go for cron-based external monitoring using find and stuff like that. Maybe even with login scripting for extra triggering. I know that dovecot supports inotify (not sure how or in what way, and ianap, so may be totally off base), so maybe that could be leveraged? -- Best regards, Charles
Re: [Dovecot] Need help with details for new Dovecot plugin - was: Re: (no subject)
On 2012-01-12 6:17 PM, Timo Sirainen t...@iki.fi wrote: On 11.1.2012, at 20.53, Geoffrey Broadwell wrote: So now the hard part is writing the piece that I can't just crib from elsewhere -- making sure that I hook every place in Dovecot that the user's voicemail folder can be changed in a way that would change it between having one or more unread messages, and not having any unread messages at all (or vice-versa, of course). At the same time, I want to minimize the performance impact to Dovecot (and the load on the UDP server) by only hooking the places I need to, filtering out as many false positives as I can without introducing massive complexity, and only pinging the UDP server when it's most likely to notice a change in the state of that user's voicemail server. I think notify plugin would help you do this the easiest way. See mail_log plugin for an example of how to use it. Oops, should have read all messages before replying (I usually skip messages with (no subject), but I try to read everything on some lists (dovecot is one of them)... Timo - searching on 'inotify' or 'notify' on both wiki1 and wiki2 has 'no results'... maybe the search indexes need to be updated? Or, is it just that there really is no documentation of inotify on either of the wikis? -- Best regards, Charles
[Dovecot] Dsync and compressed mailboxes
Hi, I will begin two migrations next week, and in both cases I plan to use compressed mailboxes with mdbox format. But in the last minute one doubt has appeared: is dsync aware of compressed mailboxes? I'm not sure if dsync -u $USER mirror mdbox:compressed_mdbox_path works, or if I have to use something else (I guess that with a running dovecot dsync backup should work). Thanks.
[Dovecot] Using Dovecot-auth to return error code 450 (or other 4xx) to Postfix when user is on vacation
Hello to all members. I am using Dovecot for 5 years, but this is my first post here. I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address. Forging can be prevented with several Postfix settings, which I did in the past - but was forced to remove, because our company occasionaly has clients with improper configurations and those settings prevent us to receive their legitimate mail (and this of course is not good for the business). So I have though about another idea. Since I use Dovecot-auth to verify mailbox existence - I just wonder is it possible to somehow indicate specific error code (and hopefully descriptive text also) to Postfix (e.g. 450 or some other temporary failure) when the owner of the mailbox is currently on vacation ? Best wishes, IVO GELOV
Re: [Dovecot] Using Dovecot-auth to return error code 450 (or other 4xx) to Postfix when user is on vacation
On 2012-01-13 12:11 PM, IVO GELOV (CRM) i...@crm.walltopia.com wrote: I am aware of the various autoresponder scripts for vacation autoreplies (I am using Virtual Vacation 3.1 by Mischa Peters). I have an issue with auto-replies - it is vulnerable to spamming with forged email address. I think you are using an extremely old/outdated version... The latest version would not suffer this problem, because it has a lot of message types that it will *not* respond to, including messages appearing to be from yourself... Get the latest version fro the postfixadmin package. However, I don't know how to use it without also using postfixadmin (it creates databases for storing the vacation message, etc)... -- Best regards, Charles
Re: [Dovecot] MySQL server has gone away
On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen t...@iki.fi wrote:
On 13.1.2012, at 4.00, Mark Moseley wrote:
I'm running 2.0.17 and I'm still seeing a decent amount of MySQL
server has gone away errors, despite having multiple hosts defined in
my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
the same thing with 2.0.16 on Debian Squeeze 64-bit.
E.g.:
Jan 12 20:30:33 auth-worker: Error: mysql: Query failed, retrying:
MySQL server has gone away
Our mail mysql servers are busy enough that wait_timeout is set to a
whopping 30 seconds. On my regular boxes, I see a good deal of these
in the logs. I've been doing a lot of mucking with doveadm/dsync
(working on maildir-mdbox migration finally, yay!) on test boxes
(same dovecot package version) and when I get this error, despite
the log saying it's retrying, it doesn't seem to be. Instead I get:
dsync(root): Error: user ...: Auth USER lookup failed
Try with only one host in the connect string? My guess: Both the
connections have timed out, and the retrying fails as well (there is only one
retry). Although if the retrying lookup fails, there should be an error
logged about it also (you don't see one?)
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
With just one 'connect' host, it seems to reconnect just fine (using
the same tests as above) and I'm not seeing the same error. It worked
every time that I tried, with no complaints of MySQL server has gone
away.
If there are multiple hosts, it seems like the most robust thing to do
would be to exhaust the existing connections and if none of those
succeed, then start a new connection to one of them. It will probably
result in much more convoluted logic but it'd probably match better
what people expect from a retry.
Alternatively, since in all my tests, the mysql server has closed the
connection prior to this, is the auth worker not recognizing its
connection is already half-closed (in which case, it probably
shouldn't even consider it a legitimate connection and just
automatically reconnect, i.e. try #1, not the retry, which would
happen after another failure).
I'll give the idle_kill a try too. I kind of like the idea of
idle_kill for auth processes anyway, just to free up some connections
on the mysql server.
Re: [Dovecot] Dsync and compressed mailboxes
The dsync process will be aware of whatever configuration file it refers to. The best thing to do is to set up a separate instance of Dovecot with compression enabled (really not that hard to do) and point dsync to that separate instances's configuration. Mailboxes written by dsync will be compressed. On Jan 13, 2012, at 5:59 AM, Joseba Torre wrote: Hi, I will begin two migrations next week, and in both cases I plan to use compressed mailboxes with mdbox format. But in the last minute one doubt has appeared: is dsync aware of compressed mailboxes? I'm not sure if dsync -u $USER mirror mdbox:compressed_mdbox_path works, or if I have to use something else (I guess that with a running dovecot dsync backup should work). Thanks.
Re: [Dovecot] MySQL server has gone away
Am 13.01.2012 19:29, schrieb Mark Moseley:
On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen t...@iki.fi wrote:
On 13.1.2012, at 4.00, Mark Moseley wrote:
I'm running 2.0.17 and I'm still seeing a decent amount of MySQL
server has gone away errors, despite having multiple hosts defined in
my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
the same thing with 2.0.16 on Debian Squeeze 64-bit.
E.g.:
Jan 12 20:30:33 auth-worker: Error: mysql: Query failed, retrying:
MySQL server has gone away
Our mail mysql servers are busy enough that wait_timeout is set to a
whopping 30 seconds. On my regular boxes, I see a good deal of these
in the logs. I've been doing a lot of mucking with doveadm/dsync
(working on maildir-mdbox migration finally, yay!) on test boxes
(same dovecot package version) and when I get this error, despite
the log saying it's retrying, it doesn't seem to be. Instead I get:
dsync(root): Error: user ...: Auth USER lookup failed
Try with only one host in the connect string? My guess: Both the
connections have timed out, and the retrying fails as well (there is only
one retry). Although if the retrying lookup fails, there should be an error
logged about it also (you don't see one?)
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
With just one 'connect' host, it seems to reconnect just fine (using
the same tests as above) and I'm not seeing the same error. It worked
every time that I tried, with no complaints of MySQL server has gone
away.
If there are multiple hosts, it seems like the most robust thing to do
would be to exhaust the existing connections and if none of those
succeed, then start a new connection to one of them. It will probably
result in much more convoluted logic but it'd probably match better
what people expect from a retry.
Alternatively, since in all my tests, the mysql server has closed the
connection prior to this, is the auth worker not recognizing its
connection is already half-closed (in which case, it probably
shouldn't even consider it a legitimate connection and just
automatically reconnect, i.e. try #1, not the retry, which would
happen after another failure).
I'll give the idle_kill a try too. I kind of like the idea of
idle_kill for auth processes anyway, just to free up some connections
on the mysql server.
by the way , if you use sql for auth have you tried auth caching ?
http://wiki.dovecot.org/Authentication/Caching
i.e.
# Authentication cache size (e.g. 10M). 0 means it's disabled. Note that
# bsdauth, PAM and vpopmail require cache_key to be set for caching to
be used.
auth_cache_size = 10M
# Time to live for cached data. After TTL expires the cached record is no
# longer used, *except* if the main database lookup returns internal
failure.
# We also try to handle password changes automatically: If user's previous
# authentication was successful, but this one wasn't, the cache isn't used.
# For now this works only with plaintext authentication.
auth_cache_ttl = 1 hour
# TTL for negative hits (user not found, password mismatch).
# 0 disables caching them completely.
auth_cache_negative_ttl = 0
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: [Dovecot] MySQL server has gone away
On Fri, Jan 13, 2012 at 11:38 AM, Robert Schetterer
rob...@schetterer.org wrote:
Am 13.01.2012 19:29, schrieb Mark Moseley:
On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen t...@iki.fi wrote:
On 13.1.2012, at 4.00, Mark Moseley wrote:
I'm running 2.0.17 and I'm still seeing a decent amount of MySQL
server has gone away errors, despite having multiple hosts defined in
my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
the same thing with 2.0.16 on Debian Squeeze 64-bit.
E.g.:
Jan 12 20:30:33 auth-worker: Error: mysql: Query failed, retrying:
MySQL server has gone away
Our mail mysql servers are busy enough that wait_timeout is set to a
whopping 30 seconds. On my regular boxes, I see a good deal of these
in the logs. I've been doing a lot of mucking with doveadm/dsync
(working on maildir-mdbox migration finally, yay!) on test boxes
(same dovecot package version) and when I get this error, despite
the log saying it's retrying, it doesn't seem to be. Instead I get:
dsync(root): Error: user ...: Auth USER lookup failed
Try with only one host in the connect string? My guess: Both the
connections have timed out, and the retrying fails as well (there is only
one retry). Although if the retrying lookup fails, there should be an error
logged about it also (you don't see one?)
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
With just one 'connect' host, it seems to reconnect just fine (using
the same tests as above) and I'm not seeing the same error. It worked
every time that I tried, with no complaints of MySQL server has gone
away.
If there are multiple hosts, it seems like the most robust thing to do
would be to exhaust the existing connections and if none of those
succeed, then start a new connection to one of them. It will probably
result in much more convoluted logic but it'd probably match better
what people expect from a retry.
Alternatively, since in all my tests, the mysql server has closed the
connection prior to this, is the auth worker not recognizing its
connection is already half-closed (in which case, it probably
shouldn't even consider it a legitimate connection and just
automatically reconnect, i.e. try #1, not the retry, which would
happen after another failure).
I'll give the idle_kill a try too. I kind of like the idea of
idle_kill for auth processes anyway, just to free up some connections
on the mysql server.
by the way , if you use sql for auth have you tried auth caching ?
http://wiki.dovecot.org/Authentication/Caching
i.e.
# Authentication cache size (e.g. 10M). 0 means it's disabled. Note that
# bsdauth, PAM and vpopmail require cache_key to be set for caching to
be used.
auth_cache_size = 10M
# Time to live for cached data. After TTL expires the cached record is no
# longer used, *except* if the main database lookup returns internal
failure.
# We also try to handle password changes automatically: If user's previous
# authentication was successful, but this one wasn't, the cache isn't used.
# For now this works only with plaintext authentication.
auth_cache_ttl = 1 hour
# TTL for negative hits (user not found, password mismatch).
# 0 disables caching them completely.
auth_cache_negative_ttl = 0
Yup, we have caching turned on for our production boxes. On this
particular box, I'd just shut off caching so that I could work on a
script for converting from maildir-mdbox and run it repeatedly on the
same mailbox. I got tired of restarting dovecot between each test :)
Re: [Dovecot] 2.1.rc3 (1a722c7676bb):dsync umlaut problems
On 01/13/2012 04:10 AM Pascal Volk wrote: All umlauts in mailbox names are lost after converting mbox/Maildir mailboxes to mdbox. # ls -d /srv/import/Maildir/.Gel\APY-schte\ Elemente/ /srv/import/Maildir/.GelAPY-schte Elemente/ … # doveadm mailbox list -u j...@example.com Gel* Gel__schte_Elemente Oh, and child mailboxes with umlauts becomes top level mailboxes: # ls -d /srv/import/Maildir/.INBOX.Projekte.K\APY-ln /srv/import/Maildir/.INBOX.Projekte.KAPY-ln #ls -d mdbox/mailboxes/INBOX_Projekte_K__ln mdbox/mailboxes/INBOX_Projekte_K__ln Regards, Pascal -- The trapper recommends today: f007ba11.1201...@localdomain.org
[Dovecot] 2.1.rc3 (1a722c7676bb): Panic: file ostream.c: line 173 (o_stream_sendv): assertion failed: (stream-stream_errno != 0)
Hi Timo,
today some imap processes are crashed.
Regards,
Pascal
--
The trapper recommends today: f007ba11.1201...@localdomain.org
#0 0x7ff2b6e16405 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x7ff2b6e19680 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2 0x7ff2b71b7e08 in default_fatal_finish (type=LOG_TYPE_PANIC, status=0)
at failures.c:187
backtrace = 0x1ffe7f8 /usr/local/lib/dovecot/libdovecot.so.0(+0x4fde1)
[0x7ff2b71b7de1] - /usr/local/lib/dovecot/libdovecot.so.0(+0x510c7)
[0x7ff2b71b90c7] - /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7ff2b71b8...
#3 0x7ff2b71b90c7 in i_internal_fatal_handler (ctx=0x7fff28ca9070,
format=0x7ff2b71efb38 file %s: line %d (%s): assertion failed: (%s),
args=0x7fff28ca9058) at failures.c:645
status = 0
#4 0x7ff2b71b80f1 in i_panic (format=0x7ff2b71efb38 file %s: line %d
(%s): assertion failed: (%s)) at failures.c:259
ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0}
args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fff28ca9140, reg_save_area = 0x7fff28ca9080}}
#5 0x7ff2b71d52b7 in o_stream_sendv (stream=0x20350c8, iov=0x7fff28ca91b0,
iov_count=1) at ostream.c:173
_stream = 0x2035040
i = 1
total_size = 1
ret = -1
__FUNCTION__ = o_stream_sendv
#6 0x7ff2b71d51ad in o_stream_send (stream=0x20350c8, data=0x7fff28ca9207,
size=1) at ostream.c:150
iov = {iov_base = 0x7fff28ca9207, iov_len = 1}
#7 0x00417ff4 in imap_fetch_send (ctx=0x202e598, output=0x20350c8,
input=0x20bfc90, cr_skipped=false, virtual_size=908982, add_missing_eoh=false,
last_cr=0x202e640) at imap-fetch-body.c:163
msg = 0x20c6418 \nofGngâ¦8[snipped]8â¦zfMNW4nyRyK4...
i = 77
size = 1314
vsize_left = 688658
sent = 220323
ret = 77
add = 13 '\r'
blocks = false
#8 0x0041823c in fetch_stream_send (ctx=0x202e598) at
imap-fetch-body.c:219
ret = 4291850
#9 0x004185ec in fetch_stream (ctx=0x202e598, size=0x7fff28ca9340) at
imap-fetch-body.c:299
input = 0x40064
#10 0x004187a3 in fetch_data (ctx=0x202e598, body=0x20a7af0,
size=0x7fff28ca9340) at imap-fetch-body.c:332
str = 0x1ffe4a0
#11 0x00418952 in fetch_body (ctx=0x202e598, mail=0x20a8d40,
body=0x20a7af0) at imap-fetch-body.c:375
fetch_size = 0x7fff28ca9340
input = 0x20bfc90
hdr_size = {physical_size = 140733877752720, virtual_size = 4286334,
lines = 684364688}
body_size = {physical_size = 897166, virtual_size = 908982, lines = 0}
#12 0x00416b34 in imap_fetch_more_int (ctx=0x202e598) at
imap-fetch.c:461
h = 0x202e938
_data_stack_cur_id = 4
client = 0x202d8c0
handlers = 0x202e8e8
count = 3
ret = 1
__FUNCTION__ = imap_fetch_more_int
#13 0x00416d8e in imap_fetch_more (ctx=0x202e598) at imap-fetch.c:513
ret = 0
__FUNCTION__ = imap_fetch_more
#14 0x0040b816 in cmd_fetch (cmd=0x202e450) at cmd-fetch.c:224
client = 0x202d8c0
ctx = 0x202e598
args = 0x2030ca8
next_arg = 0x2030cf8
list_arg = 0x7fff28ca9870
search_args = 0x20a9f20
messageset = 0x2030dd8 21:98,100:104,131:191,201:202,206:332
ret = 1
#15 0x004144d8 in command_exec (cmd=0x202e450) at imap-commands.c:147
hook = 0x2007ca0
ret = false
#16 0x004117d9 in cmd_uid (cmd=0x202e450) at cmd-uid.c:27
command = 0x2007980
cmd_name = 0x2030dd0 fetch
#17 0x004144d8 in command_exec (cmd=0x202e450) at imap-commands.c:147
hook = 0x2007ca0
ret = false
#18 0x004134f0 in client_command_input (cmd=0x202e450) at
imap-client.c:673
client = 0x202d8c0
command = 0x7fff28ca9560
__FUNCTION__ = client_command_input
#19 0x0041374f in client_command_input (cmd=0x202e450) at
imap-client.c:724
client = 0x202d8c0
command = 0x2007938
__FUNCTION__ = client_command_input
#20 0x0041387a in client_handle_next_command (client=0x202d8c0,
remove_io_r=0x7fff28ca95fd) at imap-client.c:765
size = 82
#21 0x004138fa in client_handle_input (client=0x202d8c0) at
imap-client.c:777
_data_stack_cur_id = 3
ret = false
remove_io = false
handled_commands = false
__FUNCTION__ = client_handle_input
#22 0x00413a70 in client_input (client=0x202d8c0) at imap-client.c:816
cmd = 0x2022dc8
output = 0x20350c8
bytes = 82
__FUNCTION__ = client_input
#23 0x7ff2b71ca8ff in io_loop_call_io (io=0x209ce00) at ioloop.c:377
ioloop = 0x2006660
t_id = 2
#24 0x7ff2b71cc430 in io_loop_handler_run (ioloop=0x2006660) at
ioloop-epoll.c:213
ctx = 0x20069b0
Re: [Dovecot] Server Time 45min ahead
Hi Ralf, Thanks for your help. Dovecot stop Change the server time Dovecot start Got a warning but it worked! Thanks a lot for your help. (With dovecot 1.x) -- View this message in context: http://old.nabble.com/Server-Time-45min-ahead-tp33126760p33137241.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] MySQL server has gone away
On Fri, Jan 13, 2012 at 01:36:38AM -0800, Timo Sirainen wrote:
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
Ah, set the auth-worker timeout to less than the mysql timeout to
prevent a stale mysql connection from ever being used. I'll try that,
thanks.
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | hen...@csupomona.edu
California State Polytechnic University | Pomona CA 91768
Re: [Dovecot] MySQL server has gone away
On Fri, Jan 13, 2012 at 2:46 PM, Paul B. Henson hen...@acm.org wrote:
On Fri, Jan 13, 2012 at 01:36:38AM -0800, Timo Sirainen wrote:
Also another idea to avoid them in the first place:
service auth-worker {
idle_kill = 20
}
Ah, set the auth-worker timeout to less than the mysql timeout to
prevent a stale mysql connection from ever being used. I'll try that,
thanks.
I gave that a try. Sometimes it seems to kill off the auth-worker but
not till after a minute or so (with idle_kill = 20). Other times, the
worker stays around for more like 5 minutes (I gave up watching),
despite being idle -- and I'm the only person connecting to it, so
it's definitely idle. Does auth-worker perhaps only wake up every so
often to check its idle status?
To test, I kicked off a dsync, then grabbed a netstat:
tcp0 0 10.1.15.129:40070 10.1.52.47:3306
ESTABLISHED 29146/auth worker [
tcp0 0 10.1.15.129:33369 10.1.52.48:3306
ESTABLISHED 29146/auth worker [
tcp0 0 10.1.15.129:54083 10.1.52.49:3306
ESTABLISHED 29146/auth worker [
then kicked off this loop:
# while true; do date; ps p 29146 |tail -n1; sleep 1; done
Fri Jan 13 18:05:14 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
Fri Jan 13 18:05:15 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
More lines of the loop ...
Fri Jan 13 18:05:35 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
18:05:36.252976 IP 10.1.52.48.3306 10.1.15.129.33369: F 77:77(0) ack
92 win 91 nop,nop,timestamp 1850213473 320254609
18:05:36.288549 IP 10.1.15.129.33369 10.1.52.48.3306: . ack 78 win
913 nop,nop,timestamp 320257515 1850213473
Fri Jan 13 18:05:36 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
18:05:37.196204 IP 10.1.52.49.3306 10.1.15.129.54083: F 806:806(0)
ack 1126 win 123 nop,nop,timestamp 1534230122 320254609
18:05:37.228594 IP 10.1.15.129.54083 10.1.52.49.3306: . ack 807 win
1004 nop,nop,timestamp 320257609 1534230122
18:05:37.411955 IP 10.1.52.47.3306 10.1.15.129.40070: F 806:806(0)
ack 1126 win 123 nop,nop,timestamp 774321777 320254650
18:05:37.448573 IP 10.1.15.129.40070 10.1.52.47.3306: . ack 807 win
1004 nop,nop,timestamp 320257631 774321777
Fri Jan 13 18:05:37 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
... more lines of the loop ...
Fri Jan 13 18:10:13 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
Fri Jan 13 18:10:14 EST 2012
29146 ?S 0:00 dovecot/auth worker [0 wait, 0 passdb, 0 userdb]
^C
at which point I bailed out. Looking again a couple of minutes later,
it was gone. Nothing else was going on and the logs don't show any
activity between 18:05:07 and 18:10:44.
Re: [Dovecot] MySQL server has gone away
On Fri, Jan 13, 2012 at 11:38:28AM -0800, Robert Schetterer wrote: by the way , if you use sql for auth have you tried auth caching ? http://wiki.dovecot.org/Authentication/Caching Hmm, hadn't tried that, but flipped it on to see how it might work out. The only tradeoff is a potential delay between when an account is disabled and when it can stop authenticating. I set the timeout to 10 minutes for now, with an hour timeout for negative caching. That page says you can send a USR2 signal to the auth process for cache stats? That doesn't seem to work. OTOH, that page is for version 1, not 2; is there some other way to generate cache stats in version 2? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768
Re: [Dovecot] MySQL server has gone away
On 1/13/2012 10:29 AM, Mark Moseley wrote: connection prior to this, is the auth worker not recognizing its connection is already half-closed (in which case, it probably shouldn't even consider it a legitimate connection and just automatically reconnect, i.e. try #1, not the retry, which would happen after another failure). I don't think there's any way to tell from the mysql api that the server has closed the connection short of trying to use it and getting that specific error. I suppose that specific error could be special cased as an immediate try again with no penalty rather than considered a failure. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768
