similar to: dovecot: auth-worker: Fatal: master: service(auth-worker): child XXXXX killed with signal 11

Trying to track down a dovecot issue .... The error message is: dovecot: auth-worker: Fatal: master: service(auth-worker): child XXXXX killed with signal 11 (core not dumped - set service auth-worker { drop_priv_before_exec=yes }) The setup is dovecot 2.2.29.1 with passwd and mysql auth db's and a very basic config. both authentications work ... the symptom is that after a connection

Trying to track down a dovecot issue .... The error message is: dovecot: auth-worker: Fatal: master: service(auth-worker): child XXXXX killed with signal 11 (core not dumped - set service auth-worker { drop_priv_before_exec=yes }) The setup is dovecot 2.2.29.1 with passwd and mysql auth db's and a very basic config. both authentications work ... the symptom is that after a connection

Is is possible for you to try https://github.com/dovecot/core/commit/3c5101ffdd2a8115e03ed7180d53578765dea4c9.patch Aki > On 28 February 2019 18:03 Patrik via dovecot <dovecot at dovecot.org> wrote: > > > This bug report is similar to this issue: > https://www.dovecot.org/list/dovecot/2017-May/108116.html (https://www.dovecot.org/list/dovecot/2017-May/108116.html) >

Hi Since a recent DNF update, I see many log file entries like the following: Apr 08 16:16:36 udoo.symmetrix.ch audit[31074]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:dovecot_auth_t:s0 pid=31074 comm="auth" exe="/usr/libexec/dovecot/auth" sig=11 res=1 Apr 08 16:16:36 udoo.symmetrix.ch kernel: traps: auth[31074] general protection fault

This bug report is similar to this issue: https://www.dovecot.org/list/dovecot/2017-May/108116.html <https://www.dovecot.org/list/dovecot/2017-May/108116.html> I know it is not enough info, but every kill follows with this info: Feb 28 16:57:50 server dovecot[1511]: auth-worker: Fatal: master: service(auth-worker): child 17009 killed with signal 11 (core dumps disabled -

Have you tried: 10-master.conf service imap { drop_priv_before_exec=yes } as suggested by the error?

Hello have you manage to solve your issue. I have a Mailu/Dovecot server in production which is giving me the same error. Any help would be appreciated. -- Sent from: http://dovecot.2317879.n4.nabble.com/

do you use both fts-solr and tika by chance? On Fri, Jan 11, 2019 at 11:19 AM F?rvida <aafirvida at gmail.com> wrote: > Hello have you manage to solve your issue. I have a Mailu/Dovecot server in > production which is giving me the same error. Any help would be > appreciated. > > > > -- > Sent from: http://dovecot.2317879.n4.nabble.com/ > -- Larry Rosenman

Op 11/01/2019 om 21:07 schreef Larry Rosenman: > do you use both fts-solr and tika by chance? I doubt it. The original post is about Lucene and it fails in the Lucene code. The FTS Solr + Tika problem is caused in Dovecot lib-http. Regards, Stephan. > > On Fri, Jan 11, 2019 at 11:19 AM F?rvida <aafirvida at gmail.com > <mailto:aafirvida at gmail.com>> wrote: >

Hi List, Since we migrated from dovecot 1.2.4 to 2.2.12 with lucene as FTS engine, I have this in my error log: Apr 22 14:01:14 indexer-worker(username): Error: lucene index /var/vmail/username/lucene-indexes: IndexWriter() failed (#1): Lock obtain timed out Apr 22 14:01:14 indexer-worker: Error: indexer-worker [username at mydomain.com MailBox-1 - 20800/22707]:

All, Just move our mail servers over to a new mail server running postfix 2.11.1 and dovecot 2.2.13 and getting the subject line errors in my /var/adm/files. People are complaining of loosing their connections to the mail server. I've been able to google this error but haven't found fix for this yet. NOt sure where to put the drop-priv option in the config files either. Any

I've managed to re-compile the alpine packages inside the container, creating the debug symbols and disabling compile time optimizations, as they also disturbed the backtrace. The following output looks much more meaningful. But unfortunately there are still some symbols missing for lucene-core. Let me know if this is enough to work with. (It doesn't seem to be musl after all?) Reading

Hi, I now this is kinda impolite to ask, but I would like some feedback on this issue. I'm representing the Mailu user group here, plus the fact that my own production server is affected and starts to crash due to file corruption as a result of the indexer-worker segfaults. Last night my server became unavailable with logs like: Error: imap(tim at

Ok, thanks a lot for the reply. I'll keep digging then :) On 12/21/18 4:19 PM, Aki Tuomi wrote: > On 21.12.2018 15.01, Tim Mohlmann via dovecot wrote: >> Hi, I now this is kinda impolite to ask, but I would like some feedback >> on this issue. I'm representing the Mailu user group here, plus the fact >> that my own production server is affected and starts to crash due

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 19 December 2018 at 20:00 Tim Mohlmann via dovecot < <a href="mailto:dovecot@dovecot.org">dovecot@dovecot.org</a>> wrote: </div>

Hello, since V 2.2.11 I get that error with pop3. With imap everything is fine. Feb 12 13:06:40 server2 dovecot: pop3-login: Login: user=<user>, method=PLAIN, rip=84.183.42.55, lip=195.137.213.14, mpid=20972, TLS, TLSv1 with cipher AES128-SHA (128/128 bits) Feb 12 13:06:41 server2 dovecot: pop3(user): Fatal: master: service(pop3): child 20972 killed with signal 11 (core dumps disabled)

This is log from dovecot 2.2.10: 2014-01-13T15:34:39+01:00 server/a.b.c.d dovecot: imap(user at domain): Fatal: master: service(imap): child 6290 killed with signal 11 (core dumped) (gdb) bt full #0 0x00007fe78683aba5 in mail_cache_header_fields_read () from /usr/local/dovecot-2.2.10/lib/dovecot/libdovecot-storage.so.0 No symbol table info available. #1 0x00007fe78683890a in

Hello, I've just updated to 2.0.9 and I've got lots of these in the logs now. Jan 13 18:57:13 master: Error: service(imap): child 40100 killed with signal 11 (core not dumped - set service imap { drop_priv_before_exec=yes }) Is there a configuration change or something else I should have done while updating? I tried to get some information by loading the binary into gdb and got this:

hello. Today I had a problem (core dumped) in a dovecot installation update yesterday. After many hours I found that when one settings "protocol imap" the option "replication" causes (core dumped). In this server settings "replication" was removed leaving only the "protocol imap" (my error) I send my documentation error so they can add a validation and

Hi! After upgrade I'm noticing many coredummps, below is backtrace: $ echo "bt"|gdb .... #0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222 222 if (o_stream_zlib_send_flush(zstream) < 0) (gdb) #0 o_stream_zlib_flush (stream=0xc8be5b27640) at ostream-zlib.c:222 #1 0x00007a695e8f09cd in o_stream_flush (stream=stream at entry=0xc8be5b276d0) at