Hi, is this a know problem? Newest Dovecot 2.3.4 package from repo.dovecot.org , Debian Stretch (fully upgraded). Nov 29 14:25:11 server00 dovecot: lmtp(16854): Panic: file ostream-dot.c: line 208 (o_stream_dot_sendv): assertion failed: ((size_t)ret == sent + added) Nov 29 14:25:11 server00 dovecot: lmtp(16854): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xd25e1) [0x7fa5f7b655e1] -> /usr/lib/dovecot/libdovecot.so.0(+0xd2681) [0x7 fa5f7b65681] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa5f7acd093] -> /usr/lib/dovecot/libdovecot.so.0(+0xbb97b) [0x7fa5f7b4e97b] -> /usr/lib/dovecot/libdovecot.so.0(+0x fa4ae) [0x7fa5f7b8d4ae] -> /usr/lib/dovecot/libdovecot.so.0(o_stream_sendv+0x2e) [0x7fa5f7b8da3e] -> /usr/lib/dovecot/libdovecot.so.0(io_stream_copy+0x52) [0x7fa5f7b8e512] -> /usr /lib/dovecot/libdovecot.so.0(o_stream_send_istream+0x58) [0x7fa5f7b8e008] -> /usr/lib/dovecot/libdovecot.so.0(smtp_client_command_send_more+0x1b1) [0x7fa5f7ad7351] -> /usr/lib/dov ecot/libdovecot.so.0(+0x4a096) [0x7fa5f7add096] -> /usr/lib/dovecot/libdovecot.so.0(+0xfd0c3) [0x7fa5f7b900c3] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x75) [0x7fa5f7b 7e5d5] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x109) [0x7fa5f7b7ffd9] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x56) [0x7fa5f7b7e6e6] -> / usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7fa5f7b7e8f8] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7fa5f7af2d43] -> dovecot/lmtp [local DATA](main+ 0x240) [0x565287c30f70] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fa5f77142e1] -> dovecot/lmtp [local DATA](_start+0x2a) [0x565287c310ca] Nov 29 14:25:11 server00 dovecot: lmtp(16854): Fatal: master: service(lmtp): child 16854 killed with signal 6 (core dumps disabled - https://dovecot.org/bugreport.html#coredumps) azur
On 29 Nov 2018, at 15.46, azurit at pobox.sk wrote:> > Hi, > > is this a know problem? Newest Dovecot 2.3.4 package from repo.dovecot.org , Debian Stretch (fully upgraded). > > > > Nov 29 14:25:11 server00 dovecot: lmtp(16854): Panic: file ostream-dot.c: line 208 (o_stream_dot_sendv): assertion failed: ((size_t)ret == sent + added)Is this proxying LMTP traffic?> dovecot/lmtp [local DATA](_start+0x2a) [0x565287c310ca]Based on this I was thinking it wouldn't be. But this apparently happens only with sending SMTP/LMTP traffic with SSL. So do you think it's SSL-related with you also? https://www.dovecot.org/pipermail/dovecot/2018-November/113532.html <https://www.dovecot.org/pipermail/dovecot/2018-November/113532.html> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20181129/8ba78b72/attachment.html>
Cit?t Timo Sirainen <tss at iki.fi>:> On 29 Nov 2018, at 15.46, azurit at pobox.sk wrote: >> >> Hi, >> >> is this a know problem? Newest Dovecot 2.3.4 package from >> repo.dovecot.org , Debian Stretch (fully upgraded). >> >> >> >> Nov 29 14:25:11 server00 dovecot: lmtp(16854): Panic: file >> ostream-dot.c: line 208 (o_stream_dot_sendv): assertion failed: >> ((size_t)ret == sent + added) > > Is this proxying LMTP traffic?Yes, it is. The main server is, currently, doing standard IMAP/POP3/LMTP for some clients and also proxying IMAP/POP3/LMTP for other clients (proxying to other servers). But this one error is related to one message which is stucked in postfix queue and cannot be delivered - the error appears everytime i do 'postfix flush' (error in postfix queue is 'lost connection with <censored-domain-of-main-server>[private/dovecot-lmtp] while sending end of data -- message may be sent more than once'). There are no errors logged on proxy backend side.>> dovecot/lmtp [local DATA](_start+0x2a) [0x565287c310ca] > > Based on this I was thinking it wouldn't be. But this apparently > happens only with sending SMTP/LMTP traffic with SSL. So do you > think it's SSL-related with you also? > https://www.dovecot.org/pipermail/dovecot/2018-November/113532.html > <https://www.dovecot.org/pipermail/dovecot/2018-November/113532.html>We are, currently, not using SSL while proxying traffic.