doveadm sync - I/O has stalled

songliny songliny at synology.com
Fri Dec 30 12:37:29 UTC 2022


Hi All, We are using dovecot 2.3.19.1 We created a account with more than 1000 mail folders in Maildir format to reproduce the issue. After weeks of testing, we have found a logic that may cause dsync to encounter the error - no activity for 900 seconds.... The function, dsync_ibc_stream_input, is the callback function after some data are ready for be read. This is part of what it does. o_stream_cork(ibc->output); ibc->ibc.io_callback(ibc->ibc.io_context); o_stream_uncork(ibc->output); Normally, ibc->ibc.io_callback(ibc->ibc.io_context) reads some data and then processes it. But when dsync connects over tcps, it uses function implementations in lib-ssl-iostream to send and receive data. And this simplified call stack would result in some data are read when calling o_stream_uncork o_stream_uncork => o_stream_flush => o_stream_ssl_flush_buffer => openssl_iostream_bio_sync => openssl_iostream_bio_input If some data arrive after ibc->ibc.io_callback(ibc->ibc.io_context) and before o_stre

am_uncork, o_stream_uncork would read the data and then return. After o_stream_uncork returns, dsync then waits for new data to be read or written. But because the data had been read in o_stream_uncork, and there may be no new data to be read, dsync may then wait until timeout is met. It may happen, but it is hard to reproduce. If you also encounter this situation, you may try to use dsync over tcp connection. It does not read data when calling o_stream_uncork. As a result, it may not stuck. Back to the error itself, Maybe openssl-stream should not read data when doing uncork(flush)? Song-Lin Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dovecot.org/pipermail/dovecot/attachments/20221230/3e26eede/attachment.htm>


More information about the dovecot mailing list