nnimap gets confused after hardware suspend/resume

nnimap gets confused after hardware suspend/resume

[Antoine Levitt]

(note: this is about hardware suspend/resume, not about the
gnus-group-suspend)

Sometimes, after a suspend and resume, nnimap will lose its connection,
and fail with

Opening nnimap server on Mail...failed: * LIST (%HasNoChildren) "."
"some_mail_group"

Unable to contact server Mail: * LIST (%HasNoChildren) "."
"some_mail_group"

I'm not sure where to look to debug this further, but I'd be happy to
provide more information if needed.

Note that this is with a local imap server, run with

(setq gnus-select-method '(nnimap "Mail" (nnimap-stream shell)))
(setq imap-shell-program "/usr/sbin/dovecot --exec-mail imap")

so that the problem isn't linked with a faulty connection.

I'm not 100% sure what triggers it, and it's hard to debug. It only
seems to happen when I suspend for extended periods of time though
(typically, when I suspend at night and resume the morning after.)

Re: nnimap gets confused after hardware suspend/resume

[Tassilo Horn]

Antoine Levitt <antoine.levitt@gmail.com> writes:

Hi Antoine,

> Sometimes, after a suspend and resume, nnimap will lose its
> connection, and fail with
>
> [...]
>
> I'm not 100% sure what triggers it, and it's hard to debug. It only
> seems to happen when I suspend for extended periods of time though
> (typically, when I suspend at night and resume the morning after.)

I cannot help you, but now that you've started a thread about that, I
cry on your shoulder.  When I suspend my computer for a sufficiently
long time and wake it up again, I sometimes see these Gnus/Emacs
behaviors:

  a) Some connections broken, but I can re-open them in the server
     buffer.  After doing so, often my Gmane groups show up completely
     unread with thousands of unread messages.  After restarting
     Emacs/Gnus, all is ok again.

  b) I see the that Gnus is fetching news (probably it was doing so
     while I suspended), and Emacs is completely locked up.  C-g
     repeatedly doesn't help, so that I have to kill it.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: nnimap gets confused after hardware suspend/resume

[Lars Magne Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> I'm not sure where to look to debug this further, but I'd be happy to
> provide more information if needed.

I'm not sure how to debug this, either.

I've tried to reproduce various kinds of network failures, mostly by
switching off gnutls support, and killing the external gnutls-cli
program.  But whatever I do, Gnus just reconnects.

Does anybody have a convenient way to reproduce convincing network
failures?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: nnimap gets confused after hardware suspend/resume

[Antoine Levitt]

12/04/11 17:48, Lars Magne Ingebrigtsen
> Antoine Levitt <antoine.levitt@gmail.com> writes:
>
>> I'm not sure where to look to debug this further, but I'd be happy to
>> provide more information if needed.
>
> I'm not sure how to debug this, either.
>
> I've tried to reproduce various kinds of network failures, mostly by
> switching off gnutls support, and killing the external gnutls-cli
> program.  But whatever I do, Gnus just reconnects.
>
> Does anybody have a convenient way to reproduce convincing network
> failures?

Apparently, http://monkey.org/~dugsong/dsniff/ has a "tcpkill" utility
that can kill TCP connections (although probably not simulate timeouts
and the like) as well as a variety of programs to do nasty things to
sockets. Might be worth a try.

Although, of course, nothing ever surpasses in evilness a simple wifi
that randomly drops connections. :)

Re: nnimap gets confused after hardware suspend/resume

[Lars Magne Ingebrigtsen]

Antoine Levitt <antoine.levitt@gmail.com> writes:

> Apparently, http://monkey.org/~dugsong/dsniff/ has a "tcpkill" utility
> that can kill TCP connections (although probably not simulate timeouts
> and the like) as well as a variety of programs to do nasty things to
> sockets. Might be worth a try.

Thanks; I'll have a look.

> Although, of course, nothing ever surpasses in evilness a simple wifi
> that randomly drops connections. :)

Hehe.  True.  Perhaps I should just try debugging from my laptop...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/