Reviving Gnus after suspend/hibernation

Reviving Gnus after suspend/hibernation

[Ludovic Courtès]

Hello,

When Gnus is left plugged or has non-agentized nnimap groups, recovering
from suspend-to-RAM or hibernation has always been a problem for me:
sometimes Emacs is frozen upon resume, trying to get data from some IMAP
stream.

With Emacs 23, I would typically unfreeze it by running ‘killall
gnutls-cli’ (!).

With native GnuTLS support in Emacs 24, this is no longer possible, so
it goes like this:

--8<---------------cut here---------------start------------->8---
$ gdb $(type -P emacs) $(pidof emacs)

[...]

0x00007f2345838813 in __select_nocancel () from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
(gdb) return (int)-1
Make selected stack frame return now? (y or n) y
#0  0x00000000004eed33 in xg_select ()
(gdb) quit
A debugging session is active.

        Inferior 1 [process 2204] will be detached.

Quit anyway? (y or n) y
Detaching from program: /nix/store/0p4r2m8pscisxj5crd65x34prdrrmkz4-user-environment/bin/emacs, process 2204
--8<---------------cut here---------------end--------------->8---

It works, but I tend to think that the ergonomics could be improved.
:-)

How do you people do?

Thanks,
Ludo’.

Re: Reviving Gnus after suspend/hibernation

[Richard Riley]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> When Gnus is left plugged or has non-agentized nnimap groups, recovering
> from suspend-to-RAM or hibernation has always been a problem for me:
> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
> stream.


With 24 from git mirror, I always "q" to exit gnus and restart
it. Trying a "g" from the group directly after resume hangs it.

It would be nice for it to detect this and do smoething smarter than
sitting there polling a dead network connection.

Re: Reviving Gnus after suspend/hibernation

[Tassilo Horn]

Richard Riley <rileyrg@googlemail.com> writes:

Hi!

>> When Gnus is left plugged or has non-agentized nnimap groups,
>> recovering from suspend-to-RAM or hibernation has always been a
>> problem for me: sometimes Emacs is frozen upon resume, trying to get
>> data from some IMAP stream.
>
> With 24 from git mirror, I always "q" to exit gnus and restart
> it. Trying a "g" from the group directly after resume hangs it.

With emacs 24 from bzr as of yesterday and git gnus (today), I also have
the hangs when waking up (both computer and me ;-)).  But I can always
hit C-g to get to a usable state.  Sometimes, I have to go to the
*server* buffer to reactivate a denied connection, but that's all.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Reviving Gnus after suspend/hibernation

[Dave Abrahams]

on Tue Oct 18 2011, Tassilo Horn <tassilo-AT-member.fsf.org> wrote:

> Richard Riley <rileyrg@googlemail.com> writes:
>
> Hi!
>
>>> When Gnus is left plugged or has non-agentized nnimap groups,
>>> recovering from suspend-to-RAM or hibernation has always been a
>>> problem for me: sometimes Emacs is frozen upon resume, trying to get
>>> data from some IMAP stream.
>>
>> With 24 from git mirror, I always "q" to exit gnus and restart
>> it. Trying a "g" from the group directly after resume hangs it.
>
> With emacs 24 from bzr as of yesterday and git gnus (today), I also have
> the hangs when waking up (both computer and me ;-)).  But I can always
> hit C-g to get to a usable state.  

Beware: Lars has said that if you hit C-g while Gnus is working on
something its data structures may be corrupted.

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

Re: Reviving Gnus after suspend/hibernation

[Tassilo Horn]

Dave Abrahams <dave@boostpro.com> writes:

>> With emacs 24 from bzr as of yesterday and git gnus (today), I also
>> have the hangs when waking up (both computer and me ;-)).  But I can
>> always hit C-g to get to a usable state.
>
> Beware: Lars has said that if you hit C-g while Gnus is working on
> something its data structures may be corrupted.

That never happened, but maybe I was just lucky.  And the hangs seem to
occur only for imap where the connection cannot be reestablished.  I'm
not sure, but I think nnimap uses a permanent connection (IDLE) nowadays
to get new mail notifications immediately.

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Reviving Gnus after suspend/hibernation

[Ludovic Courtès]

Dave Abrahams <dave@boostpro.com> skribis:

> Beware: Lars has said that if you hit C-g while Gnus is working on
> something its data structures may be corrupted.

Hmm, scary!

Ludo’.

Re: Reviving Gnus after suspend/hibernation

[Steinar Bang]

>>>>> ludo@gnu.org (Ludovic Courtès):
> Dave Abrahams <dave@boostpro.com> skribis:

>> Beware: Lars has said that if you hit C-g while Gnus is working on
>> something its data structures may be corrupted.

> Hmm, scary!

I hit C-g all of the time, on one of my emacsen, when it's stuck.

And so far it has always recovered.

Re: Reviving Gnus after suspend/hibernation

[Dave Abrahams]

on Fri Oct 21 2011, Steinar Bang <sb-AT-dod.no> wrote:

>>>>>> ludo@gnu.org (Ludovic Courtès):
>> Dave Abrahams <dave@boostpro.com> skribis:
>
>>> Beware: Lars has said that if you hit C-g while Gnus is working on
>>> something its data structures may be corrupted.
>
>> Hmm, scary!
>
> I hit C-g all of the time, on one of my emacsen, when it's stuck.
>
> And so far it has always recovered.

Whether or not it does may depend on lots of things: backends, agent,
cache, etc.  Lars has said the code is generally not designed to handle
arbitrary quit's, and I take him at his word.  

Except in purely-functional languages where there is no mutation,
invariants are regularly broken and fixed up (e.g. if two lists are
supposed to be the same length, you ultimately have to modify them one
at a time).  If a quit is thrown while invariants are broken, they'll
stay that way.

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

Re: Reviving Gnus after suspend/hibernation

[Steinar Bang]

>>>>> Dave Abrahams <dave@boostpro.com>:

> Whether or not it does may depend on lots of things: backends, agent,
> cache, etc.  Lars has said the code is generally not designed to
> handle arbitrary quit's, and I take him at his word.

> Except in purely-functional languages where there is no mutation,
> invariants are regularly broken and fixed up (e.g. if two lists are
> supposed to be the same length, you ultimately have to modify them one
> at a time).  If a quit is thrown while invariants are broken, they'll
> stay that way.

Yes, well... eppur si muove... until something breaks in an unrepairable
fashion (so far it hasn't) I will continue to press `C-g' on a stuck
gnus.  Probably after the first couple of breaks as well.

Re: Reviving Gnus after suspend/hibernation

[Dave Abrahams]

on Sat Oct 22 2011, Steinar Bang <sb-AT-dod.no> wrote:

>>>>>> Dave Abrahams <dave@boostpro.com>:
>
>
>> Whether or not it does may depend on lots of things: backends, agent,
>> cache, etc.  Lars has said the code is generally not designed to
>> handle arbitrary quit's, and I take him at his word.
>
>> Except in purely-functional languages where there is no mutation,
>> invariants are regularly broken and fixed up (e.g. if two lists are
>> supposed to be the same length, you ultimately have to modify them one
>> at a time).  If a quit is thrown while invariants are broken, they'll
>> stay that way.
>
> Yes, well... eppur si muove... until something breaks in an unrepairable
> fashion (so far it hasn't) I will continue to press `C-g' on a stuck
> gnus.  Probably after the first couple of breaks as well.

Suit yourself.  Some of us can't afford to have email go missing because
Gnus gets confused :-)

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

Re: Reviving Gnus after suspend/hibernation

[Dave Abrahams]

on Tue Oct 18 2011, ludo-AT-gnu.org (Ludovic Courtès) wrote:

> Hello,
>
> When Gnus is left plugged or has non-agentized nnimap groups, recovering
> from suspend-to-RAM or hibernation has always been a problem for me:
> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
> stream.

Very familiar story.  I run a local dovecot with offlineimap to avoid it
(and for other benefits) nowadays.

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

Re: Reviving Gnus after suspend/hibernation

[Ted Zlatanov]

On Tue, 18 Oct 2011 18:39:11 +0200 ludo@gnu.org (Ludovic Courtès) wrote: 

LC> When Gnus is left plugged or has non-agentized nnimap groups, recovering
LC> from suspend-to-RAM or hibernation has always been a problem for me:
LC> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
LC> stream.

LC> With Emacs 23, I would typically unfreeze it by running ‘killall
LC> gnutls-cli’ (!).

LC> With native GnuTLS support in Emacs 24, this is no longer possible, so
LC> it goes like this:
LC> $ gdb $(type -P emacs) $(pidof emacs)

LC> [...]

LC> 0x00007f2345838813 in __select_nocancel () from /nix/store/vxycd107wjbhcj720hzkw2px7s7kr724-glibc-2.12.2/lib/libc.so.6
LC> (gdb) return (int)-1
LC> Make selected stack frame return now? (y or n) y
LC> #0  0x00000000004eed33 in xg_select ()
LC> (gdb) quit
LC> A debugging session is active.

LC>         Inferior 1 [process 2204] will be detached.

LC> Quit anyway? (y or n) y
LC> Detaching from program: /nix/store/0p4r2m8pscisxj5crd65x34prdrrmkz4-user-environment/bin/emacs, process 2204

LC> It works, but I tend to think that the ergonomics could be improved.
LC> :-)

(Assuming modern GNU/Linux system is the main focus based on your
commands)

Is there a D-BUS signal for this, and can Emacs catch it?  If so I could
try to close the open connections in that handler.

What happens on a W32 system?

Thanks
Ted

Re: Reviving Gnus after suspend/hibernation

[Ted Zlatanov]

Asking emacs-devel since the Gnus list didn't have any answers:

On Mon, 24 Oct 2011 09:23:09 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 18 Oct 2011 18:39:11 +0200 ludo@gnu.org (Ludovic Courtès) wrote: 
LC> When Gnus is left plugged or has non-agentized nnimap groups, recovering
LC> from suspend-to-RAM or hibernation has always been a problem for me:
LC> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
LC> stream.
...
TZ> (Assuming modern GNU/Linux system is the main focus based on your
TZ> commands)

TZ> Is there a D-BUS signal for this, and can Emacs catch it?  If so I could
TZ> try to close the open connections in that handler.

TZ> What happens on a W32 system?

Any help is appreciated.  I don't know anything about these system events.

Thanks
Ted

Re: Reviving Gnus after suspend/hibernation

[Jonas Hörsch]

On Thu, Oct 27 2011, Ted Zlatanov wrote:

> Asking emacs-devel since the Gnus list didn't have any answers:
>
> On Mon, 24 Oct 2011 09:23:09 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Tue, 18 Oct 2011 18:39:11 +0200 ludo@gnu.org (Ludovic Courtès) wrote: 
> LC> When Gnus is left plugged or has non-agentized nnimap groups, recovering
> LC> from suspend-to-RAM or hibernation has always been a problem for me:
> LC> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
> LC> stream.
> ...
> TZ> (Assuming modern GNU/Linux system is the main focus based on your
> TZ> commands)
>
> TZ> Is there a D-BUS signal for this, and can Emacs catch it?  If so I could
> TZ> try to close the open connections in that handler.
>
> TZ> What happens on a W32 system?
>
> Any help is appreciated.  I don't know anything about these system events.
>
> Thanks
> Ted

I'm not sure about catching a suspend event, that probably is based on
who is suspending anyway (Is it a DBUS-using power manager, like KDE's
powerdevil or the gnome-power-manager?).

But if the network interfaces are managed by NetworkManager, you can at
least hook into connect/disconnect signals. There is some working
implementation on the EmacsWiki:

http://www.emacswiki.org/emacs/GnusNetworkManager

Cheers
Jonas

Re: Reviving Gnus after suspend/hibernation

[Richard Riley]

coroa@online.de (Jonas Hörsch) writes:

> On Thu, Oct 27 2011, Ted Zlatanov wrote:
>
>> Asking emacs-devel since the Gnus list didn't have any answers:
>>
>> On Mon, 24 Oct 2011 09:23:09 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>>
>> TZ> On Tue, 18 Oct 2011 18:39:11 +0200 ludo@gnu.org (Ludovic Courtès) wrote: 
>> LC> When Gnus is left plugged or has non-agentized nnimap groups, recovering
>> LC> from suspend-to-RAM or hibernation has always been a problem for me:
>> LC> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
>> LC> stream.
>> ...
>> TZ> (Assuming modern GNU/Linux system is the main focus based on your
>> TZ> commands)
>>
>> TZ> Is there a D-BUS signal for this, and can Emacs catch it?  If so I could
>> TZ> try to close the open connections in that handler.
>>
>> TZ> What happens on a W32 system?
>>
>> Any help is appreciated.  I don't know anything about these system events.
>>
>> Thanks
>> Ted
>
> I'm not sure about catching a suspend event, that probably is based on
> who is suspending anyway (Is it a DBUS-using power manager, like KDE's
> powerdevil or the gnome-power-manager?).
>
> But if the network interfaces are managed by NetworkManager, you can at
> least hook into connect/disconnect signals. There is some working
> implementation on the EmacsWiki:
>
> http://www.emacswiki.org/emacs/GnusNetworkManager
>

NetworkManager is uninstalled by many of us because it can be buggy, is
poor at handling VPNs and "does its own thing" rather than respect the
interfaces file. So if this could be done at a point common to both NM
*and* manual interfaces/wpa__supplicant handling that would be better.

Re: Reviving Gnus after suspend/hibernation

[Antoine Levitt]

27/10/11 19:41, Ted Zlatanov
> Asking emacs-devel since the Gnus list didn't have any answers:
>
> On Mon, 24 Oct 2011 09:23:09 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
>
> TZ> On Tue, 18 Oct 2011 18:39:11 +0200 ludo@gnu.org (Ludovic Courtès) wrote: 
> LC> When Gnus is left plugged or has non-agentized nnimap groups, recovering
> LC> from suspend-to-RAM or hibernation has always been a problem for me:
> LC> sometimes Emacs is frozen upon resume, trying to get data from some IMAP
> LC> stream.
> ...
> TZ> (Assuming modern GNU/Linux system is the main focus based on your
> TZ> commands)
>
> TZ> Is there a D-BUS signal for this, and can Emacs catch it?  If so I could
> TZ> try to close the open connections in that handler.
>
> TZ> What happens on a W32 system?
>
> Any help is appreciated.  I don't know anything about these system events.
>
> Thanks
> Ted

Just a data point: I used to have tons of issues like this one (and
basically used to quit and run gnus again every time I resumed from
suspend). I no longer have any. I _think_ it's because I switched from
using a shell connection to a local TCP connection. Also, I used to get
random hangs, even with a TCP connection, and they disappeared magically
a couple of months ago. I don't know who did that, but good job :-)