dovecot replication crashing
Hi,
I'm a but clueless, having issues with replication. `doveadm dsync -u hans`
works.
But using the following replication setup, I see coredumps.
Where to go next?
Interestingly not for all users. (For testing purposes I've only 2
users. One having about 20 messages: here even the replication works,
but the 2nd user (having about 14k messages) fails. The failure seems to
happen immediatly after starting the replication attempt).
I saw the replication crashing using Dovecot packages from the current
Debian distro. In order to debug this, I'm now using 2.3.20, built from
Git.
The replicator config boils down to this (complete config is attached)
replication_full_sync_interval = 90d
replication_max_conns = 16
mail_plugins = $mail_plugins notify replication
plugin {
mail_replica = tcps:smtp-mz.example.com:9090
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
service aggregator {
fifo_listener replication-notify-fifo {
user = dovecot
mode = 0666
}
unix_listener replication-notify {
user = dovecot
mode = 0666
}
}
The stacktrace I get looks like this:
Stack trace of thread 729589:
#0 0x7f9e4f2c8ce1 __GI_raise (libc.so.6 + 0x38ce1)
#1 0x7f9e4f2b2537 __GI_abort (libc.so.6 + 0x22537)
#2 0x7f9e4f5fe8c6 default_fatal_finish (libdovecot.so.0 + 0x558c6)
#3 0x7f9e4f6ab601 i_internal_fatal_handler (libdovecot.so.0 + 0x102601)
#4 0x7f9e4f5fe589 i_panic (libdovecot.so.0 + 0x55589)
#5 0x7f9e4f5fe99e fd_set_nonblock (libdovecot.so.0 + 0x5599e)
#6 0x5564cbe6a08d cmd_dsync_ibc_stream_init (doveadm-server + 0x3008d)
#7 0x5564cbe6b772 cmd_dsync_run (doveadm-server + 0x31772)
#8 0x5564cbe6d284 doveadm_mail_next_user (doveadm-server + 0x33284)
#9 0x5564cbe6e4ba doveadm_mail_cmd_exec (doveadm-server + 0x344ba)
#10 0x5564cbe7eb71 doveadm_cmd_run_ver2 (doveadm-server + 0x44b71)
#11 0x5564cbe8300a doveadm_cmd_server_run_ver2 (doveadm-server + 0x4900a)
#12 0x7f9e4f6c1799 io_loop_call_io (libdovecot.so.0 + 0x118799)
#13 0x7f9e4f6c2e82 io_loop_handler_run_internal (libdovecot.so.0 + 0x119e82)
#14 0x7f9e4f6c1840 io_loop_handler_run (libdovecot.so.0 + 0x118840)
#15 0x7f9e4f6c1a00 io_loop_run (libdovecot.so.0 + 0x118a00)
#16 0x7f9e4f6343a3 master_service_run (libdovecot.so.0 + 0x8b3a3)
#17 0x5564cbe5d9a2 main (doveadm-server + 0x239a2)
#18 0x7f9e4f2b3d0a __libc_start_main (libc.so.6 + 0x23d0a)
#19 0x5564cbe5da2a _start (doveadm-server + 0x23a2a)
2023 Mar 28 00:09:28 clone doveadm(hans)<729589>:
Fatal: master: service(doveadm): child 729589 killed with signal 6 (core dumped)
I'm a bit clueless now, even using the coredump and gdb.
--
Heiko
# 2.3.20 (80a5ac675d): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.20 (149edcf2)
# OS: Linux 5.10.0-10-amd64 x86_64 Debian 11.6
# Hostname: clone
auth_cache_negative_ttl = 5 mins
auth_cache_size = 64 M
auth_cache_ttl = 5 mins
auth_master_user_separator = *
auth_username_format = %Ln
default_client_limit = 8192
default_process_limit = 2048
doveadm_password = # hidden, use -P to show it
first_valid_uid = 996
haproxy_trusted_networks =
imap_id_log = *
imap_id_send = *
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
login_trusted_networks = 10.0.0.0/8
mail_gid = vmail
mail_location =
maildir:~/Maildir:INBOX=/var/vmail/inbox/%u:VOLATILEDIR=/var/vmail/cache/%u:INDEX=/var/vmail/index/%u
mail_plugins = quota notify notify replication
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace inbox {
inbox = yes
location =
mailbox Archive {
auto = subscribe
}
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 = /etc/dovecot/master-users
driver = passwd-file
master = yes
}
passdb {
args = cache_key=#hidden_use-P_to_show#
driver = pam
}
plugin {
autocreate = Trash
autocreate2 = Junk
autocreate3 = Drafts
autocreate4 = Sent
autosubscribe = Trash
autosubscribe2 = Junk
autosubscribe3 = Drafts
autosubscribe4 = Sent
mail_compress_save = bz2
mail_compress_save_level = 9
mail_replica = tcps:smtp-mz.example.com:9090
quota = maildir:user
quota_rule = *:storage=11GB
quota_rule2 = Archive*:ignore
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_after = /etc/dovecot/sieve-after.d/
sieve_before = /etc/dovecot/sieve-before.d/
}
protocols = imap pop3 lmtp sieve
replication_full_sync_interval = 90 day
Re: How to use dovecot with more recent versions of solr (8x, 9x)?
* j...@w3.org, 27.03.23 15:28 [...] Could someone confirm me if those 7.7.0 configuration files are compatible with 8.11.2? A diff between those files and the ones from the 8.11.2 dist reveal some changes, starting from the LuceneVersion. [...] Following https://dovecot.org/pipermail/dovecot/2022-May/124701.html and its replies worked fine here upgrading to 8.11.2. Have not tried 9.x yet, though. HTH Thomas
Re: doveadm expunge unnecessarily tries to access TLS key
On 2023-03-27 16:31, Aki Tuomi wrote: On 27/03/2023 16:42 EEST Jesper Dybdal wrote: I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to Bullseye (Dovecot 2.3.13). The Dovecot server works fine, which of course is the really important thing. But I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night. That worked fine in 2.3.4, but now it fails: jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail? (I could give it a "-u jdmobile" option and run it as root - but I really like to run things like that as a non-privileged user, so I won't make a stupid mistake that destroys the wrong mailbox.) Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk Hi! This is a known issue, to work around it, use ssl=no !include_try conf.d/ssl.conf and put ssl=yes in ssl.conf along with your cert & key. then chmod it 0600. This is also fixed in 2.3.20. Thank you very much! The workaround seems to work just fine. Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: doveadm expunge unnecessarily tries to access TLS key
> On 27/03/2023 16:42 EEST Jesper Dybdal wrote: > > > I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to > Bullseye (Dovecot 2.3.13). > > The Dovecot server works fine, which of course is the really important > thing. > > But I have a cron job that cleans up all old mail from the mailbox that > I use for my mobile phone by running "doveadm expunge" every night. > > That worked fine in 2.3.4, but now it fails: > > jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d > > doveconf: Fatal: Error in configuration file > > /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file > > /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied > > Of course, doveadm cannot access the TLS key when running as a normal > user. But why should it try to access that key at all when I have just > asked it to clean up my own files in my own Maildir? Is there a way to > make it not try to access that key and do its job anyway? Or another > way to delete old mail? > > (I could give it a "-u jdmobile" option and run it as root - but I > really like to run things like that as a non-privileged user, so I won't > make a stupid mistake that destroys the wrong mailbox.) > > Thanks, > Jesper > > -- > Jesper Dybdal > https://www.dybdal.dk Hi! This is a known issue, to work around it, use ssl=no !include_try conf.d/ssl.conf and put ssl=yes in ssl.conf along with your cert & key. then chmod it 0600. This is also fixed in 2.3.20. Aki
doveadm expunge unnecessarily tries to access TLS key
I have just upgraded my Debian Buster (Dovecot 2.3.4, I think it was) to Bullseye (Dovecot 2.3.13). The Dovecot server works fine, which of course is the really important thing. But I have a cron job that cleans up all old mail from the mailbox that I use for my mobile phone by running "doveadm expunge" every night. That worked fine in 2.3.4, but now it fails: jdmobile@nuser:~$ doveadm expunge mailbox '*' before 25d doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 23: ssl_cert: Can't open file /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem: Permission denied Of course, doveadm cannot access the TLS key when running as a normal user. But why should it try to access that key at all when I have just asked it to clean up my own files in my own Maildir? Is there a way to make it not try to access that key and do its job anyway? Or another way to delete old mail? (I could give it a "-u jdmobile" option and run it as root - but I really like to run things like that as a non-privileged user, so I won't make a stupid mistake that destroys the wrong mailbox.) Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
How to use dovecot with more recent versions of solr (8x, 9x)?
Hello, dovecot version 2.3.13 (89f716dc2) The dovecot solr installation guide [1] gives links and configuration info for sorl 7.7.0. However, sorl was deprecated some time ago. Those links to 7.7.0 don't work anymore. Sorl is currently available in versions 8.11.2 and 9.1.1 [3]. Specifically, one section in the guide states [2]: [[ Install schema.xml and solrconfig.xml Copy doc/solr-config-7.7.0.xml and doc/solr-schema-7.7.0.xml (Since Dovecot 2.3.6+) to /var/solr/data/dovecot/conf/ as solrconfig.xml and schema.xml. The managed-schema file is generated based on schema.xml. ]] Could someone confirm me if those 7.7.0 configuration files are compatible with 8.11.2? A diff between those files and the ones from the 8.11.2 dist reveal some changes, starting from the LuceneVersion. If they are not compatible, could someone tell me what changes were done in the doc/solr files that need to be replicated in the 8.x and 9.x versions? The doc is very opaque there as it only states that you should replace those files but doesn't go into details as to why, making it confusing on how to upgrade to a new version of solr. It would be great if the dovecot/solr doc page could be upgraded to reflect the new versions of solr. Thanks in advance for your help, --jose [1] https://doc.dovecot.org/configuration_manual/fts/solr/ [2] https://doc.dovecot.org/configuration_manual/fts/solr/#solr-configuration [3] https://downloads.apache.org/lucene/solr/
