Noticed this didn't get posted on the list, so reposting... On Wed, Oct 26 2016, Oswald Buddenhagen wrote: > On Tue, Oct 25, 2016 at 10:53:19PM +0200, Yuri D'Elia wrote: >> where the journal file looks simply truncated (probably not flushed). >> The actual file content is: >> >> 00000000: 320a 0000 0000 0000 0000 0000 0000 0000 2............... >> 00000010: 0000 0000 0000 0000 0000 0000 0000 .............. >> >> I remember asking in the list how robust the journal mechanism, but it >> doesn't seem reliable enough for mbsync to be SIGTERM'ed/interrupted. >> > that doesn't make sense to me. a signal may not alter what gets written > to the file, only how much of it is written. zero-padding may only > happen as a response to internal inconsistency, which a sane kernel > positively will not introduce itself just because something interrupted > a userspace process. > maybe you can strace your cron job to see what is happening.
It's hard to reproduce at will. The incomplete journal is consistently the INBOX folder of an outlook365 server. But this is because this is also the slowest folder to sync, and thus most likely to be interrupted. As for truncation, this might still happen if the file is not fsynced explicitly at critical transaction points (including before fclose). I didn't look at the code yet, so I'm just reporting what I'm seeing and guessing at this point. > i'm collecting error messages and grepping them. that way i filter out > all the silly noise from outlook. > getting proper exit code handling is kinda tough, because mbsync can > perform multiple independent jobs - do you report the best or the worst? > i guess it would be possible to write a precise report file with one > line per mailbox. however, undoubtedly the best solution would be > letting mbsync handle transient errors and the timing itself. I would actually be pretty happy to have two (or more) ORed flags for the exit status as many tools already do, in order to distinguish the broad categories. For example. !=0 is any problem, but then the status&0x0F range could mark just transient error classes (such as connection/timeout errors). As an end-user, I can decide what to do. My plan would be allow for up to three transient errors to pass without notice, or any non-transient error to be notified immediately. Easily done in *sh. Logs are a PITA to parse, and technically I could already do this by parsing the regular output (which I'd like to avoid). ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
