bug#28596: 26.0.60; [Gnus] Checking mail is no longer reliable and C-g no longer quits

[N. Jackson]

At 13:14 -0400 on Monday 2017-09-25, Noam Postavsky wrote:
>
> Does 'pkill -SIGUSR2 emacs' help? Otherwise running under gdb and
> hitting C-z at the gdb terminal should give some more info.
>
> (elisp) Error Debugging
>
> -- User Option: debug-on-event
>      If you set ‘debug-on-event’ to a special event (*note Special
>      Events::), Emacs will try to enter the debugger as soon as it
>      receives this event, bypassing ‘special-event-map’.  At present,
>      the only supported values correspond to the signals ‘SIGUSR1’ and
>      ‘SIGUSR2’ (this is the default).  This can be helpful when
>      ‘inhibit-quit’ is set and Emacs is not otherwise responding.

Hi Noam,

Thanks for these tips.

I'm now running under GDB but so far today the long hang isn't
happening so I haven't been able to get a backtrace during it.
Nevertheless, after putting Gnus into an unplugged state and then
putting it into the plugged state while my computer was still
disconnected from the Internet, Gnus is now in a broken state even
though I now am connected.

The problem can be easily seen in the *Server* buffer. All my nntp
servers are broken. (My local servers (nnfolder, nndraft, and my
nnimap server on localhost) are fine.)

- The nntp servers that are managed by the Agent are in an
  "offline" state even though Gnus is currently plugged (and I
  have a good Internet connection), and the `O', `C' and `R'
  (open, close, and reset all) commands have not effect. (Toggling
  the plugged/unplugged state a few times hasn't changed this
  brokenness.)

- The nntp servers that are not managed by the Agent are in a
  "denied" state and the `O', `C' and `R' (open, close, and reset
  all) commands have not effect.

And when I say these commands have no effect, they have no effect
at all. No messages are written to the *Messages* buffer even
though I have gnus-verbose and gnus-verbose-backends both set to
10. [The former setting doesn't seem to do anything (hasn't for a
year or two), but the latter normally prints the dialog with the
servers.]

That is, it seems that Gnus is not even trying to talk to these
servers.

It almost seems as if, because they were found once in the Emacs
session not to be accessible, Gnus will never try to talk to them
again until Emacs is restarted, and commands in the *Server*
buffer to open, close etc. these servers are just quietly ignored.

I will report more as I find it, maybe look at the code, possibly
step through it in the debugger. But as my every day workflow is
so much effected by this I might have to go back to Emacs 25 where
these problems don't happen.

N.