- dovecot - dovecot.org

[Dovecot] Plugins: virtuals vs acls
by Leho Kraav 20 Sep '16

20 Sep '16

Hi all dovecot-virtual: * all when dovecot-acl files restrict some subset of * for a user, does dovecot respect these ACLs when collecting messages for virtual folder? I'd like a confirmation about what I should be seeing when I start implementing this setup.

2 3

Dovecot and imapproxy
by Grant 20 Sep '16

20 Sep '16

imapproxy sped things up a lot for me when I was using courier. I switched to dovecot a while back and kept using imapproxy. Lately I've been noticing weird TCP Queuing spikes in my munin graphs and discontinuing my use of imapproxy seems to have smoothed them out completely and I haven't noticed a slowdown in webmail. Is imapproxy generally not necessary with dovecot? - Grant

2 1

Re: Dovecot 2.2.25 fails on SSL
by Joseph Tam 19 Sep '16

19 Sep '16

"Andreas M. Kirchwitz" <amk(a)spamfence.net> writes: >> OK, the origin of your problem becomes clearer. You can hardcode these >> paths into the executables by doing something like >> >> env CFLAGS='-I/my'ssl/include' \ >> LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \ >> configure ... > > Based on your mail I've tried CFLAGS/LDFLAGS again, and > now Dovecot didn't even compile any longer. I don't use the same OS as you, but what errors dis you get? Joseph Tam <jtam.home(a)gmail.com>

1 0

Panic: file auth-request.c
by Chris Wik 19 Sep '16

19 Sep '16

Hello Dovecot list, We've been running a really old CentOS 5 server with the stock dovecot from yum (1.0.7) for years and years with absolutely no problems. If it ain't broke, don't fix it, or something like that. Well it finally broke, but only due to the server no longer being able to handle the load of the increasing user base (many thousands now, with hundreds of concurrent IMAP connections any any given time) So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and tons of RAM. No more load problems. We compiled the latest dovecot from source (as the version from CentOS yum repo is already quite old, figure we might as well run the latest version since we were upgrading anyway). Thanks to excellent documentation on dovecot.org and fairly thorough testing, the upgrade was quite smooth. We kept all the message UUIDs intact and tried to match the supported authentication methods etc to the old setup, and we didn't have any problems with clients re-downloading or re-syncing mail. We do however have one problem, which prompted me to join this list. It is the same problem as described in this thread from last month: http://dovecot.org/list/dovecot/2016-July/104899.html Here's the excerpt from our maillog: Sep 17 19:34:57 mail dovecot: auth: Panic: file auth-request.c: line 1049 (auth_request_lookup_credentials): assertion failed: (request->credentials_scheme == scheme) Sep 17 19:34:57 mail dovecot: auth: Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0x89470) [0x7fa9cb8af470] -> /usr/local/lib/dovecot/libdovecot.so.0(+0x8954e) [0x7fa9cb8af54e] -> /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa9cb851f75] -> dovecot/auth() [0x4165bc] -> dovecot/auth() [0x4221fb] -> dovecot/auth() [0x41620b] -> dovecot/auth(auth_request_lookup_credentials_callback+0x58) [0x4162f8] -> dovecot/auth(passdb_handle_credentials+0x6a) [0x4254ba] -> dovecot/auth() [0x425b62] -> dovecot/auth() [0x41c1f8] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x4c) [0x7fa9cb8c207c] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xd7) [0x7fa9cb8c3377] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x25) [0x7fa9cb8c2105] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7fa9cb8c22b8] -> /usr/local/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7fa9cb857f33] -> dovecot/auth(main+0x2eb) [0x40ccdb] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fa9c9dc2b15] -> dovecot/auth() [0x40cf15] On the client side, it manifests as an authentication failure, and the user is prompted to re-enter their password. The reports we've had are all from users who have their passwords saved in a local password manager, so the client is definitely sending the correct password. It's not related to a particular mail client. It is also definitely not related to the particular user or password, as the user will authenticate many times successfully and then (seemingly) randomly be hit by this bug and prompted to re-enter their password. We enabled verbose logging and even logging of passwords for failed authentication attempts in an attempt to find a pattern, but so far we have not found one. Similar to the original poster in the above thread, we are using a MySQL backend, and CentOS 7 on x86_64 It happens quite frequently: in the past 6 days it happened 49175 times, according to a grep of the maillog. In the same period there were 294167 successful IMAP logins and 160322 POP3 logins. For now we have downgraded to 2.2.4 and so far have not seen the crash recorded in the maillog. What can we do to help track down and fix this bug? # dovecot -n # 2.2.24 (a82c823): /usr/local/etc/dovecot/dovecot.conf # OS: Linux 3.10.0-327.28.3.el7.x86_64 x86_64 CentOS Linux release 7.2.1511 (Core) ext4 auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login digest-md5 cram-md5 ntlm rpa apop auth_verbose = yes auth_verbose_passwords = plain debug_log_path = /var/log/dovecot-debug.log default_client_limit = 5000 default_process_limit = 1000 disable_plaintext_auth = no first_valid_uid = 89 mail_debug = yes mail_fsync = never mail_gid = 89 mail_location = maildir:/var/virtual/%d/%n mail_uid = 89 namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf.ext driver = sql } pop3_client_workarounds = outlook-no-nuls oe-ns-eoh service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } ssl_ca = <*** ssl_cert = <*** ssl_key = <*** userdb { args = /usr/local/etc/dovecot/dovecot-sql.conf.ext driver = sql } verbose_ssl = yes protocol lmtp { mail_fsync = optimized } protocol lda { mail_fsync = optimized } protocol imap { mail_max_userip_connections = 50 } protocol pop3 { mail_max_userip_connections = 20 } -- Chris Wik Anu Internet Services www.anu.net | www.cwik.ch

3 5

dovecot --hostdomain
by dovecot＠nspace.de 19 Sep '16

19 Sep '16

Hi, I'm currently debugging replication issues and I found that both servers answer to a "dovecot --hostdomain" simply with localhost From what I've read, this can lead to problems. Where do I configure the dovecot hostdomain name? The machine itself has a valid name in /etc/hostname Thanks, Thomas

2 1

Re: Dovecot 2.2.25 fails on SSL
by Andreas M. Kirchwitz 19 Sep '16

19 Sep '16

Joseph Tam <jtam.home(a)gmail.com> wrote: >> For every program I compile myself, I link it against my custom >> OpenSSL library (always newest version; distributions usually tend >> to stick with a specific version and only apply security fixes). > > OK, the origin of your problem becomes clearer. You can hardcode these > paths into the executables by doing something like > > env CFLAGS='-I/my'ssl/include' \ > LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \ > configure ... Yes, exactly, that's my usual approach. I've used this as well for building other software with custom libraries. Unfortunately, I remember CFLAGS/LDFLAGS didn't play well with Dovecot, so I used SSL_CFLAGS/SSL_LIBS as suggested by the documentation and that worked well. > I use this myself (except the -Wl part since these libs are > symlinked to my shared library path). I think "-R/my/ssl/lib" > might also be synonymous with -Wl,... Based on your mail I've tried CFLAGS/LDFLAGS again, and now Dovecot didn't even compile any longer. I was close to giving up. But obviously, I didn't ... :-) After some investigation I found the non-default linker option "-Wl,--as-needed" as problem which is enabled by Dovecot for unknown reasons. Finally, this call to "configure" generates proper Makefile files to build Dovecot with a custom SSL library: env CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib -Wl,-R/usr/local/ssl/lib" LIBS="-Wl,--no-as-needed -lcrypto -lssl" SSL_CFLAGS="-I/usr/local/ssl/include" SSL_LIBS="-L/usr/local/ssl/lib -Wl,-R/usr/local/ssl/lib -Wl,--no-as-needed -lcrypto -lssl" ./configure --prefix=/usr/local/dovecot --with-ssl=openssl (chances are that SSL_CFLAGS/SSL_LIBS could be removed completely but it won't hurt) I've read the section in the "ld" manual but still don't understand why Dovecot enables --as-needed (never seen that before with other software) and why it's such a big problem. But I'm no expert here. > I don't have that problem -- I use configure to tell dovecot where to find > my self-compiled openssl, and the resulting executables load from where I > want. Thanks for pointing me at the proper direction again. Now Dovecot 2.2.25 compiles for me with a custom SSL. I understand that this issue might not have a high priority but maybe one of the developers could check if "--as-needed" is really needed (as it confuses people who try to use custom libraries) and what's the deeper meaning of SSL_CFLAGS/SSL_LIBS. My system is a regular CentOS 6 (latest sub-release with all patches), nothing special except for a custom SSL installation. Greetings, Andreas

1 0

BUG - DELETE Public/Folder not working with Thunderbird
by Leander Schäfer 18 Sep '16

18 Sep '16

Hi, Unfortunately it looks like the parameter: "imap_client_workarounds = tb-extra-mailbox-sep" does not work. Neither inside nor outside "protocol imap {}" configuration section. ACLs are set correctly. Manual "DELETE Public/Test" via telnet is working as expected. Is this a known bug? See: - https://help.ubuntu.com/community/Dovecot#Thunderbird - http://wiki.dovecot.org/Clients#Thunderbird # 2.2.25 (7be1766): /usr/local/etc/dovecot/dovecot.conf # Pigeonhole version 0.4.15 (97b3da0) # OS: FreeBSD 10.3-RELEASE amd64 [...] imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags [...] namespace { list = children location = maildir:%%h/maildir:INDEX=~/maildir/Shared/%%u:CONTROL=~/maildir/Shared/%%u:INDEXPVT=~/maildir/Shared prefix = Shared/%%u/ separator = / subscriptions = no type = shared } namespace { hidden = no list = children location = maildir:~/../Public:LAYOUT=fs:INDEX=~/../Public:CONTROL=~/../Public:INDEXPVT=~/maildir/Public prefix = Public/ separator = / subscriptions = no type = public } [...] Best regards Leander Schäfer

2 4

how to mass delete after a hacked mail?
by voytek＠sbt.net.au 17 Sep '16

17 Sep '16

I had a hacked user account resulting in several thousand bounces back to that email inbox, account now corrected, but, how can I mass delete bounces with say subject like: "Undelivered Mail Returned to Sender" (by from ? ""Mail Delivery System" <MAILER-DAEMON(a)emu.sbt.net.au>") or what other ways to clean the mess ? thanks, V

4 3

converting maildir to mailbox
by Anton Yuzhaninov 16 Sep '16

16 Sep '16

Hi all! There is a script to convert maildir to mailbox in wiki: http://wiki.dovecot.org/Migration/MailFormat but it doesn't convert any message flags (seen e.t.c.). I wrote a script, which converts most flags and labels: https://bitbucket.org/citrin/scripts/src/tip/dovecot-maildir2mbox.pl It doesn't convert recent flag and UIDs though, because it was not necessary in my case. Do you think link to the script should be added to dovecot wiki? -- WBR, Anton Yuzhaninov P. S. My use case was: get maildir from other server, convert to mbox, compress (gzip -9) and add to my mailbox as read-only archive.

3 2

Crash with latest -git as of 2.2.devel (c06590c)
by Reuben Farrelly 16 Sep '16

16 Sep '16

Hi, Looks like something has been committed to master-2.2 in the last week which is causing crashes as soon as the remote user logs in: Sep 17 01:11:19 thunderstorm.reub.net dovecot: dsync-server(reuben): Error: read(lightning.reub.net) failed: EOF (last sent=mailbox_state, last recv=mail (EOL)) Sep 17 01:11:31 thunderstorm.reub.net dovecot: imap(reuben): Panic: file fts-api.c: line 128 (fts_backend_set_cur_mailbox): assertion failed: (ctx->cur_box != NULL) Sep 17 01:11:31 thunderstorm.reub.net dovecot: imap(reuben): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0xb7f9f) [0x7f4cd5b4cf9f] -> /usr/lib64/dovecot/libdovecot.so.0(+0xb9515) [0x7f4cd5b4e515] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7f4cd5b4d332] -> /usr/lib64/dovecot/lib20_fts_plugin.so(+0x96b4) [0x7f4cd50b86b4] -> /usr/lib64/dovecot/lib20_fts_plugin.so(fts_backend_update_deinit+0x45) [0x7f4cd50b872b] -> /usr/lib64/dovecot/lib20_fts_plugin.so(+0x142ed) [0x7f4cd50c32ed] -> /usr/lib64/dovecot/libdovecot-storage.so.0(maildir_sync_index+0x98e) [0x7f4cd5e4eed7] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0x5f209) [0x7f4cd5e51209] -> /usr/lib64/dovecot/libdovecot-storage.so.0(+0x5f497) [0x7f4cd5e51497] -> /usr/lib64/dovecot/libdovecot-storage.so.0(maildir_storage_sync_init+0xb2) [0x7f4cd5e517de] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x6d) [0x7f4cd5e2cc41] -> dovecot/imap(imap_sync_init+0xc7) [0x42e408] -> dovecot/imap() [0x42f96b] -> dovecot/imap() [0x42febc] -> dovecot/imap(cmd_sync_delayed+0x34) [0x42fef2] -> dovecot/imap(client_handle_input+0x138) [0x41e9d1] -> dovecot/imap(client_input+0xf5) [0x41eb02] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0xcd) [0x7f4cd5b6b054] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x209) [0x7f4cd5b6d5c1] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x24) [0x7f4cd5b6b1fd] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0xaf) [0x7f4cd5b6b149] -> /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x2e) [0x7f4cd5aca603] -> dovecot/imap(main+0x300) [0x431169] -> /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f4cd571c710] -> dovecot/imap(_start+0x29) [0x40c7b9] Sep 17 01:11:31 thunderstorm.reub.net dovecot: imap(reuben): Fatal: master: service(imap): child 1740 killed with signal 6 (core dumped) thunderstorm reuben # file core core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'dovecot/imap postlogin', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/usr/libexec/dovecot/imap', platform: 'x86_64' thunderstorm reuben # gdb /usr/libexec/dovecot/imap core GNU gdb (Gentoo 7.11.1 vanilla) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/libexec/dovecot/imap...done. [New LWP 1740] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `dovecot/imap postlogin'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f4cd572f1f8 in raise () from /lib64/libc.so.6 (gdb) bt full #0 0x00007f4cd572f1f8 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x00007f4cd573064a in abort () from /lib64/libc.so.6 No symbol table info available. #2 0x00007f4cd5b4cfee in default_fatal_finish (type=LOG_TYPE_PANIC, status=0) at failures.c:201 backtrace = 0x27446a0 "/usr/lib64/dovecot/libdovecot.so.0(+0xb7f9f) [0x7f4cd5b4cf9f] -> /usr/lib64/dovecot/libdovecot.so.0(+0xb9515) [0x7f4cd5b4e515] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7f4cd5b4d332] -> /usr"... #3 0x00007f4cd5b4e515 in i_internal_fatal_handler (ctx=0x7fff509f3750, format=0x7f4cd50cb000 "file %s: line %d (%s): assertion failed: (%s)", args=0x7fff509f3770) at failures.c:670 status = 0 #4 0x00007f4cd5b4d332 in i_panic (format=0x7f4cd50cb000 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:275 ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, timestamp_usecs = 0} args = <error reading variable args (Attempt to dereference a generic pointer.)> #5 0x00007f4cd50b86b4 in fts_backend_set_cur_mailbox (ctx=0x26f6e70) at fts-api.c:128 __FUNCTION__ = "fts_backend_set_cur_mailbox" #6 0x00007f4cd50b872b in fts_backend_update_deinit (_ctx=0x268b3b8) at fts-api.c:143 ctx = 0x26f6e70 backend = 0x26825e0 ret = 32588 #7 0x00007f4cd50c32ed in fts_mailbox_sync_notify (box=0x268aaa0, uid=0, sync_type=(unknown: 0)) at fts-storage.c:665 flist = 0x2683000 fbox = 0x268b258 #8 0x00007f4cd5e4eed7 in maildir_sync_index (ctx=0x268eb40, partial=true) at maildir-sync-index.c:649 mbox = 0x268aaa0 view = 0x26f4f30 view2 = 0x0 iter = 0x0 trans = 0x270ef20 hdr = 0x268b8b0 empty_hdr = {major_version = 176 '\260', minor_version = 57 '9', base_header_size = 20639, header_size = 32767, record_size = 3588796538, compat_flags = 76 'L', unused = "\177\000", indexid = 1352612272, flags = 32512, uid_validity = 40955680, next_uid = 0, messages_count = 40849200, unused_old_recent_messages_count = 0, seen_messages_count = 40857728, deleted_messages_count = 0, first_recent_uid = 136, first_unseen_uid_lowwater = 0, first_deleted_uid_lowwater = 40428608, log_file_seq = 0, log_file_tail_offset = 1352612384, log_file_head_offset = 32767, unused_old_sync_size = 139967982787820, unused_old_sync_stamp = 40913568, day_stamp = 0, day_first_uid = { 41174496, 0, 41174440, 0, 40413856, 0, 1352612384, 32767}} rec = 0x26d7188 seq = 0 seq2 = 0 uid = 1043 prev_uid = 1043 uflags = (MAILDIR_UIDLIST_REC_FLAG_MOVED | MAILDIR_UIDLIST_REC_FLAG_RECENT | MAILDIR_UIDLIST_REC_FLAG_NONSYNCED) filename = 0x2711a00 "1474037293.M664229P7078.thunderstorm,S=18760,W=19334:2,Sd" uid_validity = 1466133870 next_uid = 3585376580 hdr_next_uid = 1044 first_recent_uid = 1044 first_uid = 1 changes = 1 ret = 0 time_before_sync = 1474038691 expunged_guid_128 = "\247\332=\207\337[1\a\367\217\025\307\024|-Y" private_flags_mask = 0 expunged = true full_rescan = false __FUNCTION__ = "maildir_sync_index" #9 0x00007f4cd5e51209 in maildir_sync_context (ctx=0x27445a8, forced=false, find_uid=0x0, lost_files_r=0x7fff509f3afa) at maildir-sync.c:951 sync_flags = MAILDIR_UIDLIST_SYNC_PARTIAL flags = (MAILDIR_UIDLIST_REC_FLAG_NEW_DIR | MAILDIR_UIDLIST_REC_FLAG_MOVED | MAILDIR_UIDLIST_REC_FLAG_RECENT | MAILDIR_UIDLIST_REC_FLAG_NONSYNCED | MAILDIR_UIDLIST_REC_FLAG_RACING | unknown: 32736) new_changed = false cur_changed = false lock_failure = false fname = 0x268aaa0 "" why = (unknown: 0) ret = 1 __FUNCTION__ = "maildir_sync_context" #10 0x00007f4cd5e51497 in maildir_sync_run (mbox=0x268aaa0, flags=MAILBOX_SYNC_FLAG_EXPUNGE, force_resync=false, uid=0x0, lost_files_r=0x7fff509f3afa) at maildir-sync.c:1024 _data_stack_cur_id = 5 ctx = 0x27445a8 retry = false lost_files = false ret = 0 #11 0x00007f4cd5e517de in maildir_storage_sync_init (box=0x268aaa0, flags=MAILBOX_SYNC_FLAG_EXPUNGE) at maildir-sync.c:1097 mbox = 0x268aaa0 lost_files = false force_resync = false ret = 0 __FUNCTION__ = "maildir_storage_sync_init" #12 0x00007f4cd5e2cc41 in mailbox_sync_init (box=0x268aaa0, flags=MAILBOX_SYNC_FLAG_EXPUNGE) at mail-storage.c:1728 _data_stack_cur_id = 4 ctx = 0x0 #13 0x000000000042e408 in imap_sync_init (client=0x2687680, box=0x268aaa0, imap_flags=IMAP_SYNC_FLAG_SAFE, flags=MAILBOX_SYNC_FLAG_EXPUNGE) at imap-sync.c:229 ctx = 0x268b770 __FUNCTION__ = "imap_sync_init" #14 0x000000000042f96b in cmd_sync_client (sync_cmd=0x2688280) at imap-sync.c:737 client = 0x2687680 ctx = 0x2 flags = MAILBOX_SYNC_FLAG_EXPUNGE imap_flags = IMAP_SYNC_FLAG_SAFE no_newmail = false #15 0x000000000042febc in cmd_sync_delayed_real (client=0x2687680) at imap-sync.c:858 cmd = 0x2688280 first_expunge = 0x2688280 first_nonexpunge = 0x0 __FUNCTION__ = "cmd_sync_delayed_real" #16 0x000000000042fef2 in cmd_sync_delayed (client=0x2687680) at imap-sync.c:866 _data_stack_cur_id = 3 ret = 80 #17 0x000000000041e9d1 in client_handle_input (client=0x2687680) at imap-client.c:1118 ret = false remove_io = false handled_commands = true __FUNCTION__ = "client_handle_input" #18 0x000000000041eb02 in client_input (client=0x2687680) at imap-client.c:1149 cmd = 0x7fff509f3cc0 output = 0x26880a0 bytes = 28 __FUNCTION__ = "client_input" #19 0x00007f4cd5b6b054 in io_loop_call_io (io=0x268ca30) at ioloop.c:564 ioloop = 0x264f760 t_id = 2 __FUNCTION__ = "io_loop_call_io" #20 0x00007f4cd5b6d5c1 in io_loop_handler_run_internal (ioloop=0x264f760) at ioloop-epoll.c:220 ctx = 0x2651270 events = 0x26520a0 event = 0x26520a0 list = 0x26881d0 io = 0x268ca30 tv = {tv_sec = 256, tv_usec = 707889} events_count = 5 msecs = 256708 ret = 1 i = 0 j = 0 call = true __FUNCTION__ = "io_loop_handler_run_internal" #21 0x00007f4cd5b6b1fd in io_loop_handler_run (ioloop=0x264f760) at ioloop.c:612 No locals. #22 0x00007f4cd5b6b149 in io_loop_run (ioloop=0x264f760) at ioloop.c:588 __FUNCTION__ = "io_loop_run" #23 0x00007f4cd5aca603 in master_service_run (service=0x264f600, callback=0x430dd6 <client_connected>) at master-service.c:641 No locals. #24 0x0000000000431169 in main (argc=2, argv=0x264f390) at main.c:460 set_roots = {0x43bbe0 <imap_setting_parser_info>, 0x646340 <lda_setting_parser_info>, 0x0} login_set = {auth_socket_path = 0x2647048 "\001", postlogin_socket_path = 0x2647078 "z`\005", postlogin_timeout_secs = 60, callback = 0x430af0 <login_client_connected>, failure_callback = 0x430d41 <login_client_failed>, request_auth_token = 1} service_flags = MASTER_SERVICE_FLAG_KEEP_CONFIG_OPEN storage_service_flags = (MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT | MAIL_STORAGE_SERVICE_FLAG_AUTOEXPUNGE) username = 0x0 auth_socket_path = 0x43cd85 "auth-master" c = -1 (gdb) Reuben

1 0