On Fri, Jul 01, 2022 at 03:19:12PM +0200, Oswald Buddenhagen wrote: > On Fri, Jul 01, 2022 at 03:10:54PM +0200, Yuri D'Elia wrote: > > But I can definitely start taking a note if you want more detailed info > > in where it gets stuck. > > > yes, please. make the external timeout long enough so that it accomodates > isync's timeout on top of a reasonably worst-case time for a successful > sync, so you don't get false positives.
I also run mbsync under timeout(1). As far as I remember, almost all the cases where mbsync got stuck was on read(2) syscall. It looks like socket reading is implemented without timer, so it allows very common scenario of one-side connection loss. As one guy from linux-net said, "read() without timer is a bug". :) -- Eugene Berdnikov _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
