Dropped unread state

[Dave Abrahams]

on Tue Sep 27 2011, Sebastian Spaeth <Sebastian-AT-SSpaeth.de> wrote:

> On Mon, 26 Sep 2011 06:50:54 -0400, Dave Abrahams <dave at boostpro.com> wrote:
>
> I don't see how IMAP<->IMAP should work better than IMAP<->Maildir as it
> uses the same sync logic.

Well, the one possibility that leaps to mind is that there is then only
one agent (the IMAP server) manipulating the Maildir message store,
rather than two (the IMAP server and offlineimap).  It seems as though
the IMAP server ought to have an advantage in coordinating things to
maintain consistency.

>> 2. I suspect that I restart offlineimap far more often than he does.
>>    How well is offlineimap designed to cope with getting a SIGKILL in
>>    the middle of a run?
>
> It is designed to not lose mail data, but I cannot promise that a wrong flag
> might ensue in some cases when you kill it before it manages to update
> the status cache or so. It usually should not hurt to abort, but I have
> been wrong before...
>
> It usually use SIGINT for bailing out. Also SIGUSR1 and SIGUSR2
> work nicely and SIGUSR2 will shut down cleanly:

Oh, I clearly read your emails in the wrong order (oops).  Is any of the
following information in the docs?

> If sent a SIGUSR1 it will abort any current (or next future) sleep of all
> accounts that are configured to "autorefresh". In effect, this will trigger a
> full sync of all accounts to be performed as soon as possible.
>
> If sent a SIGUSR2, it will stop "autorefresh mode" for all accounts. That is,
> accounts will abort any current sleep and will exit after a currently running
> synchronization has finished. This signal can be used to gracefully exit out of
> a running offlineimap "daemon".

Oh, that's very nice.  Hmm, it looks to me as though there's no way to
integrate this with launchd (MacOSX) for a graceful exit.  These are the only
options it seems to offer:

,----[ `Man launchd.plist' ]
|  ...
|  EnableTransactions <boolean>
|  This flag instructs launchd that the job promises to use
|  vproc_transaction_begin(3) and vproc_transaction_end(3) to track out-
|  standing transactions that need to be reconciled before the process can
|  safely terminate. If no outstanding transactions are in progress, then
|  launchd is free to send the SIGKILL signal.
|  ...
|  ExitTimeOut <integer>
|  The amount of time launchd waits before sending a SIGKILL signal. The
|  default value is 20 seconds. The value zero is interpreted as infinity.
|  ...
`----

Hmm, it also says:

,----
|  A daemon or agent launched by launchd SHOULD:
| 
|        ...
|        o   Catch the SIGTERM signal.
`----

So maybe offlineimap should also respond to SIGTERM as though it were
SIGUSR2?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com