On Thu, Feb 23 2017, Oswald Buddenhagen wrote: >> I see the use case when running as a daemon. >> >> You still need to specify the indexing status to the child process >> though. Would the same scheme be fine? >> > i'm not sure i understand the question ... > > i'd spawn one notifier per successful run on a single box.
I should have written/meant "sync status" or process status. I'd like to know if, for instance, there's a transient failure (such as connection error that I should not worry about). > alternatively, one could just dump json to a file (which may be a fifo). Mmmh, to give you an idea, this is roughly what I do in my cron job: if [ $(network-name) = "work" ]; then timeout 180 mbsync -qae else timeout 30 mbsync -qne inboxes fi ret=$? # timeout, no change or transient error respectively [ $ret = 124 -o $ret = 4 -o $ret = 12 ] && exit 0 notmuch update exit $ret It's actually quite simple and very powerful. I wouldn't be able to do this in daemon mode, for example. I actually have different groups that I sync at different frequency intervals, or some groups that I only sync when I'm in certain networks. > well, in the easiest case, you can configure "touch ~/.mailbox-changed" > as your notifier. dealing with that is arguably _easier_ than with a > bit-field exit code: test -f. I guess this would come in handy if you wanted to process imap mail locally. But seems overkill just for a general status change. > one thing to consider: you're really just interested in changes on the > slave, so it probably makes sense to realize the whole thing > asymmetrically. this is equally true for your approach. Yes, I thought about that, since the counters are already split. But I can actually avoid running the re-index in the vast majority of the cases that even by combining them that it didn't seem necessary. > it's just attached to the crashed process, so you can use it > interactively. when you're done, you exit, which is when the crashed > process also exits. > i'll note that this isn't bullet-proof, as the used functions aren't > signal-safe. still, it has proven useful. I generally simply allow the tests to dump core when I know the bug is not reproducible, otherwise I run it under gdb manually. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
