- dovecot - dovecot.org

Googling: dovecot: auth-worker(default): pam_start() failed: Critical error - immediate abort
by david＠davidwbrown.name 17 May '15

17 May '15

Howdy, Googling: dovecot: auth-worker(default): pam_start() failed: Critical error - immediate abort dobbeltganger dovecot: auth-worker(default): pam(user,1.2.3.4): lookup service=dovecot dobbeltganger out of memory [4543] returns just 3 references. Examining memory server side reveals use of virtual memory but not 100% OS: Ubuntu 14.04 client 10.04 server-side. Email client: Thunderbird (Thunderbird prompts for the password which has worked for years). dovecot -n # 1.2.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.34.1-rscloud x86_64 Ubuntu 10.04.4 LTS log_timestamp: %Y-%m-%d %H:%M:%S ssl: required verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-logina login_processes_count: 5 login_max_processes_count: 256 mail_max_userip_connections: 40 mail_privileged_group: mail mail_location: maildir:~/Maildir mail_debug: yes mbox_write_locks: fcntl dotlock auth default: realms: davidwbrown.name, karlbrown.name default_realm: dobbeltganger.com username_format: %n verbose: yes debug: yes debug_passwords: yes passdb: driver: pam userdb: driver: passwd socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix

1 0

How do I fix this: master: Warning: fd limit (ulimit -n) is lower than required
by Robert Chalmers 16 May '15

16 May '15

I get this when I reload dovecot after any changes. How can I fix it? I can’t find any reference to it anywhere. master: Warning: fd limit (ulimit -n) is lower than required under max. load (256 < 1000), because of default_client_limit thanks Robert

3 5

fs_api_module_register
by Eric Broch 16 May '15

16 May '15

Hello list, I'm trying to build a binary rpm from dovecot sources 2.2.18 and pigeonhole.0.4.8. During the make portion I'm getting the following error: make[3]: Leaving directory `/root/rpmbuild/BUILD/dovecot-2.2.18/src/lib-storage' for bin in test-mail-search-args-imap test-mail-search-args-simplify test-mailbox-get; do \ if ! /bin/sh ../../run-test.sh ../.. ./$bin; then exit 1; fi; \ done /root/rpmbuild/BUILD/dovecot-2.2.18/src/lib-storage/.libs/lt-test-mail-search-args-imap: symbol lookup error: /root/rpmbuild/BUILD/dovecot-2.2.18/src/lib-storage/.libs/lt-test-mail-search-args-imap: undefined symbol: fs_api_module_register I created a binary rpm from dovecot sources 2.2.16 and pigeonhole sources 0.4.7 and all went well. Can anyone give me any hints as to the problem? Eric

2 2

Core dump at imap process
by Dominik Breu 16 May '15

16 May '15

hello list, testing the 2.18 release i got following core dump. Maybe Timo you can get a look at it. greetings dominik Core Dump: root@hbs-buko:/var/vmail/hbs-buko.info/dominik.breu# gdb /usr/lib/dovecot/imap core GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 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-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. 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/lib/dovecot/imap...Reading symbols from /usr/lib/debug//usr/lib/dovecot/imap...done. done. [New LWP 4069] Core was generated by `dovecot/imap'. Program terminated with signal SIGSEGV, Segmentation fault. #0 imap_msgpart_contains_body (msgpart=0x0) at imap-msgpart.c:311 311 imap-msgpart.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 imap_msgpart_contains_body (msgpart=0x0) at imap-msgpart.c:311 No locals. #1 0x00007f4eba177054 in fetch_state_update_stats (msgpart=<optimized out>, ctx=0x7f4ebacfa910, ctx=0x7f4ebacfa910) at imap-fetch-body.c:169 No locals. #2 0x00007f4eba17747b in fetch_rfc822_header (ctx=0x7f4ebacfa910, mail=0x7f4ebad08a10, context=<optimized out>) at imap-fetch-body.c:529 msgpart = 0x0 str = <optimized out> #3 0x00007f4eba1754cc in imap_fetch_more_int (ctx=ctx@entry=0x7f4ebacfa910, cancel=false) at imap-fetch.c:506 h = <optimized out> _data_stack_cur_id = 4 state = 0x7f4ebacfa960 client = 0x7f4ebacf9bb0 count = <optimized out> ret = <optimized out> __FUNCTION__ = "imap_fetch_more_int" #4 0x00007f4eba1765ca in imap_fetch_more (ctx=0x7f4ebacfa910, cmd=cmd@entry=0x7f4ebacfa7b0) at imap-fetch.c:558 ret = <optimized out> __FUNCTION__ = "imap_fetch_more" #5 0x00007f4eba169864 in cmd_fetch (cmd=0x7f4ebacfa7b0) at cmd-fetch.c:286 client = <optimized out> ctx = 0x7f4ebacfa910 args = 0x7f4ebace2b08 next_arg = <optimized out> list_arg = 0x7f4ebad03b50 search_args = 0x0 qresync_args = {qresync_sample_seqset = 0x7f4ebacd71f8, qresync_sample_uidset = 0x1} messageset = 0x7f4ebace2c70 "353" send_vanished = <optimized out> ret = <optimized out> #6 0x00007f4eba173cbc in command_exec (cmd=cmd@entry=0x7f4ebacfa7b0) at imap-commands.c:167 hook = 0x7f4ebace00f0 diff = <optimized out> finished = <optimized out> #7 0x00007f4eba172b32 in client_command_input (cmd=0x7f4ebacfa7b0) at imap-client.c:828 client = 0x7f4ebacf9bb0 command = <optimized out> __FUNCTION__ = "client_command_input" #8 0x00007f4eba172f2d in client_handle_next_command (remove_io_r=<synthetic pointer>, client=0x7f4ebacf9bb0) at imap-client.c:926 No locals. #9 client_handle_input (client=0x7f4ebacf9bb0) at imap-client.c:938 _data_stack_cur_id = 3 remove_io = false handled_commands = false client = 0x7f4ebacf9bb0 #10 0x00007f4eba1732f5 in client_input (client=0x7f4ebacf9bb0) at imap-client.c:980 cmd = 0xea880 output = 0x7f4ebacfa5d0 bytes = 2 __FUNCTION__ = "client_input" #11 0x00007f4eb99a2b6c in io_loop_call_io (io=0x7f4ebacfa6c0) at ioloop.c:501 ioloop = 0x7f4ebacdf740 t_id = 2 __FUNCTION__ = "io_loop_call_io" ---Type <return> to continue, or q <return> to quit--- #12 0x00007f4eb99a3ba5 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x7f4ebacdf740) at ioloop-epoll.c:220 ctx = 0x7f4ebace0460 io = <optimized out> tv = {tv_sec = 1799, tv_usec = 999300} events_count = <optimized out> msecs = <optimized out> ret = 1 i = 0 j = <optimized out> call = <optimized out> __FUNCTION__ = "io_loop_handler_run_internal" #13 0x00007f4eb99a2bd9 in io_loop_handler_run (ioloop=ioloop@entry=0x7f4ebacdf740) at ioloop.c:548 No locals. #14 0x00007f4eb99a2c58 in io_loop_run (ioloop=0x7f4ebacdf740) at ioloop.c:525 __FUNCTION__ = "io_loop_run" #15 0x00007f4eb9941243 in master_service_run (service=0x7f4ebacdf5d0, callback=<optimized out>) at master-service.c:581 No locals. #16 0x00007f4eba16696c in main (argc=1, argv=0x7f4ebacdf390) at main.c:431 set_roots = {0x7f4eba38b940 <imap_setting_parser_info>, 0x0} login_set = {auth_socket_path = 0x7f4ebacd7048 "\001", postlogin_socket_path = 0x0, postlogin_timeout_secs = 60, callback = 0x7f4eba17ccc0 <login_client_connected>, failure_callback = 0x7f4eba17c930 <login_client_failed>, request_auth_token = 1} service_flags = <optimized out> storage_service_flags = <optimized out> username = 0x0 c = <optimized out>

2 2

Dovecot Replication - Architecture Endianness?
by Reuben Farrelly 15 May '15

15 May '15

Hi all, I've had an interesting use case come up which - to cut the story short - one way to solve the problem I am looking at may be to replicate a small number of mailboxes to a third remote server. I've currently had replication running between my main dovecot machine and another remote VM for some time and working well (so I'm not new to replication and I've got a good working config), but I've a need to add a third to the mix for a select number of mailboxes. The arch on both of those is Gentoo x86_64 and with latest 2.1.16 -hg. I have attempted this so far by rsync'ing the initial Maildirs and then once the bulk of the data has been transferred rely on dovecot's replication to keep things in sync. I figure that this should in theory mean that the subsequent updates in both directions are incremental and the bulk of the data gets moved while the device is here on my desk using rsync. I've attempted to do this using a Raspberry Pi as a remote device, but when I set it up the dovecot replication process seems to need to start the replication over from scratch even after the rsync is done. I know this is happening as the disk utilisation on the Pi skyrockets once the replication starts and I end up with thousands of double ups of all the mails ... which defeats the entire point of the process. If I do an identical configuration but on a third Gentoo x86_64 VM locally it all works as expected. No double ups of mails and the "catchup" between the two devices is practically instant. Same filesystem even. The only difference appears to be the system architecture. So main my question is this. Is there a known architecture/endian limitation on replication? I guess cross-arch replication is not something many people try but is it supposed to work anyway? Has anyone else got replication working across different arch's? Also is there a way to restrict replication users aside from a crude hack around system first and last UIDs? Thanks, Reuben

3 10

Re: imap_logout_format improvements
by Joseph Tam 15 May '15

15 May '15

Timo Sirainen wrote: > So all in all, you can now add to imap_logout_format: >... > Any thoughts on what else would be useful? Maybe quota stats like number of quota errors, or quota usage? Bytes used by Email marked \Deleted? Joseph Tam <jtam.home(a)gmail.com>

2 1

Re: [Dovecot] IMAP and POP3 operations log per user
by Miloš Dukić 15 May '15

15 May '15

On 05/14/15 23:49, Jorge Bastos wrote: > Hi, > > > > I'd like to have a log per user, and protocol (imap+pop3), where this log > would tell me/save the message sender+subject+operation (deleted, marked to > expunge/other/was read/other). > > Is there something similar to this that already exists? > > > > If not is there something like this on the TODO/whishlist? > > > > Thanks in advanced, > > Jorge Bastos > . > Jorge, Per user loggin is not available. You can enable Dovecot events in 10-logging.conf. Just uncomment mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename in plugin section. Depending on your setup, it will be logged to /var/log/maillog, or whatever you defined in your syslog configuration.

1 0

Released Pigeonhole v0.4.8 for Dovecot v2.2.18
by Stephan Bosch 15 May '15

15 May '15

Hello Dovecot users, Here is the final 0.4.8 release. No significant changes were committed since the last release candidate. Changelog v0.4.8: * LDA Sieve plugin: Dovecot changed the deliver_log_format setting to include %{delivery_time}. This prompted changes in Pigeonhole that make this release dependent on Dovecot v2.2.17. + Implemented magic to make sieve_default script visible from ManageSieve under a configurable name. This way, users can see the default rules, edit them and store a private adjusted version. This could also be achieved by copying the default script into the user's script storage, but updates to the global sieve_default script would be ignored that way. + ManageSieve: Implemented support for reporting command statistics at disconnect. Statistics include the number of bytes and scripts uploaded/downloaded/checked and the number of scripts deleted/renamed. - Fixed problem in address test: erroneously decoded mime-encoded words in address headers. - extprograms plugin: Fixed failure occurring when connecting to script service without the need to read back the output from the external program. - Fixed bug in script storage path normalization occurring with relative symbolic links below root. - Fixed and updated various parts of the documentation - ManageSieve: Used "managesieve" rather than "sieve" as login service name, which means that all managesieve-specific settings where ignored. - Managesieve: Storage quota was not always enforced properly for scripts uploaded as quoted string. Nobody uses that, but it is allowed in the specification and we support it, so it should work properly. The release is available as follows: http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.8.tar… http://pigeonhole.dovecot.org/releases/2.2/dovecot-2.2-pigeonhole-0.4.8.tar… Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch stephan(a)rename-it.nl

1 0

Many Duplicated messages after migrate from 2.0.19 to 2.2.15
by Listas＠Adminlinux 15 May '15

15 May '15

Hi, In my company, we have several failover clusters (~50k accounts per cluster) with Ubuntu12.04 and Dovecot-2.0.19 (without dsync, replication at block level with DRBD). We are migrating to active/active clusters with Ubuntu14.04 and Dovecot-2.2.15 with replication via dovecot-dsync. Each new cluster consists of two machines and each machine runs two instances of Dovecot (one for backend and the other for proxy Dovecot-director). We did the migration of message files, indexes and sieve scripts using rsync to one of the backends. After we turn on the second backend and let the dsync work in replication for him. Now, many accounts are with duplicated messages and some new emails delivered are also being duplicated. Doveadm deduplicate doesn't work for me. I ran: doveadm deduplicate -u <user> -m ALL Does do the migration of files with rsync was a mistake ? We are using mdbox on both clusters. My confs with doveconf -n for both clusters: http://www.adminlinux.com.br/newcluster_doveconf.txt http://www.adminlinux.com.br/oldcluster_doveconf.txt Thanks and regards, Thiago Henrique

1 0

v2.2.18 released
by Timo Sirainen 15 May '15

15 May '15

http://dovecot.org/releases/2.2/dovecot-2.2.18.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.18.tar.gz.sig Oops, director was somewhat broken in 2.2.17. I thought I tested the last changes in it well enough, but looks like not. To avoid all existing Dovecot director installations from breaking I decided to make 2.2.18 release quickly afterwards.. BTW. We're planning on making some changes soon to how version control is used in Dovecot development, which should help avoid these kind of problems. The main problem now is that everything gets directly committed to the master branch (although we have a separate more stable dovecot-ee repo also). The new plan is to do something like this: http://nvie.com/posts/a-successful-git-branching-model/ Besides some minor compiling issues and other small changes, the important ones are: - director: Login UNIX sockets were normally detected as doveadm or director ring sockets, causing it to break in existing installations. - sdbox: When copying a mail in alt storage, place the destination to alt storage as well.

3 2