offlineimap hangs

[Nicolas Sebrecht]

On Sun, Jan 11, 2015 at 11:53:01PM +0000, Edd Barrett wrote:

> No, I actually wrote my own password manager. The code is here:
> https://github.com/vext01/passout

After a very quick review, I'd say you should thread the process relying
on external tools and set a timeout on them. Once the timeout expires,
raise an exception from the main thread.

> Hrm, you reckon it missed the server's answer... Maybe this is because
> the wireless network was missing as the machine resumed.

Probably, yes. Or the authentication request was partially sent and
imaplib2 has assumptions about socket beeing open.

> It usually takes a few seconds for the wireless to come back.

This is a lot of time. :-)

> > I have no strong opinion about this one. What should we do? Hardcode a
> > timer to each call to our main library? Seriously?
> 
> Does socktimeout not apply here?

socktimeout applies at socket level.

I can think of two scenario:

- socktimeout had not the time to occur and imaplib2 does not handle
  correctly the failures at IMAP protocol level: it should retry by
  itself. If no response it should raise an exception once a timeout or a
  number of retries exceeded. I'll now assume it's not the
  logic/philosophy of the library. If no response at the first attempt, it
  should break the connection once a timeout exceed and raise an
  exception.

- socktimeout occured and imaplib2 does not nicely handle that neither.
  It should raise an exception while it seems to still wait for a
  response on a broken socket.

Now, look at how wrong is socktimeout from the beginning. OfflineIMAP
has to set the socket timeout by itself. Did we miss an option of the
library or doesn't imaplib2 actually takes care of that (like it should,
IMHO)?

Was imaplib2 process stopped at the wait() call? Or is it a just a
random statement which is in a loop?

Another possible scenario would be that OfflineIMAP loops itself and
send again and again the same request. I doubt on this because we
already did a lot of work in this area in the past and we could never
find such a loop. Of course, everything remains possible.

As I said, it requires more investigations. :-/

> > Anyway, I'd like to ask you create an issue about the last trace. It's a
> > good one and I feel we won't come with the simple fix in the coming
> > days.
> 
> Will do, probably tomorrow.

Thank you much.

-- 
Nicolas Sebrecht