On Fri, Jul 01, 2022 at 01:03:11PM +0200, Yuri D'Elia wrote:
A good distinction could really be if retrying makes sense or not.
yes, but the followup questions are then: retry after how much time, and
how often? it's hard to know that if you don't know *exactly* what went
wrong.
otoh, network errors are always somewhat unreliable, e.g. you might get
NXDOMAIN (which is technically a terminal error) just because the
network is down and your home router is too stupid to report it
correctly (true story).
in short, it's a mess.
mbsync can currently get stuck during slow/blocked transfers in
multiple places, most commonly during resolve or during connect.
resolve is indeed synchronous and its timeout outside isync's control. i
need to do something about that ...
but if you find tangible evidence for isync's Timeout not working in
some other scenario, i'm all ears.
i suppose the most promising way to debug this would be running with -D
(maybe -Dn is sufficient) and saving away the logs where the process got
killed by timeout.
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
