Gnus development mailing list
 help / color / mirror / Atom feed
* new wifi connection = nntp timeout = Emacs restart?
@ 2020-04-16 17:37 Eric Abrahamsen
  2020-04-17 11:46 ` Eric S Fraga
  2020-04-19  6:37 ` Christian Barthel
  0 siblings, 2 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-16 17:37 UTC (permalink / raw)
  To: ding

Hi all,

Has anyone noticed that if you put your laptop to sleep while attached
to one wifi network, then wake it up somewhere else and let it attach to
a new network, nntp servers refuse to reconnect? In most cases, they
refuse so hard that not only do I have to restart Gnus, I have to
restart all of Emacs. I used to think it was my imagination, but it's
happened too many times by now.

Has anyone else seen this? What could be lingering in an Emacs session
that would permanently prevent reconnection?

Eric



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-16 17:37 new wifi connection = nntp timeout = Emacs restart? Eric Abrahamsen
@ 2020-04-17 11:46 ` Eric S Fraga
  2020-04-17 12:20   ` Gijs Hillenius
  2020-04-19  6:37 ` Christian Barthel
  1 sibling, 1 reply; 67+ messages in thread
From: Eric S Fraga @ 2020-04-17 11:46 UTC (permalink / raw)
  To: ding

Anecdotally, I think I have experienced the same in the past.  And,
sometimes, even if still re-connecting to the same network.  So much so
that I have gotten into the habit of quitting gnus (but not Emacs) if
I'm putting my laptop to sleep.
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.6 on Debian bullseye/sid



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-17 11:46 ` Eric S Fraga
@ 2020-04-17 12:20   ` Gijs Hillenius
  2020-04-17 12:26     ` Andreas Schwab
  0 siblings, 1 reply; 67+ messages in thread
From: Gijs Hillenius @ 2020-04-17 12:20 UTC (permalink / raw)
  To: ding

On 17 April 2020 12:46 Eric S Fraga, wrote:

> Anecdotally, I think I have experienced the same in the past.  And,
> sometimes, even if still re-connecting to the same network.  So much so
> that I have gotten into the habit of quitting gnus (but not Emacs) if
> I'm putting my laptop to sleep.

Yes, I do that too. And when I forget, I /have/ to quit Gnus when I wake
up the laptop, or else hitting g will make Gnus just hang out there for
a long time before it returns empty handed.



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-17 12:20   ` Gijs Hillenius
@ 2020-04-17 12:26     ` Andreas Schwab
  2020-04-17 14:51       ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Andreas Schwab @ 2020-04-17 12:26 UTC (permalink / raw)
  To: Gijs Hillenius; +Cc: ding

On Apr 17 2020, Gijs Hillenius wrote:

> Yes, I do that too. And when I forget, I /have/ to quit Gnus when I wake
> up the laptop, or else hitting g will make Gnus just hang out there for
> a long time before it returns empty handed.

Does it work to close the servers (gnus-close-all-servers)?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-17 12:26     ` Andreas Schwab
@ 2020-04-17 14:51       ` Eric Abrahamsen
  2020-04-17 15:38         ` David Engster
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-17 14:51 UTC (permalink / raw)
  To: ding

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Apr 17 2020, Gijs Hillenius wrote:
>
>> Yes, I do that too. And when I forget, I /have/ to quit Gnus when I wake
>> up the laptop, or else hitting g will make Gnus just hang out there for
>> a long time before it returns empty handed.
>
> Does it work to close the servers (gnus-close-all-servers)?

I use "z" sort of compulsively, any time I haven't touched Gnus for a
while. (I've also put all my nntp groups at level 5 and all my nnimap
groups at level 3, so I can do "3 g" and not worry about it.)

"z" usually works, but the point of this thread was that, when I switch
network connections, it often *doesn't*, and neither does restarting
Gnus. I've got to kill all of Emacs.

Eric



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-17 14:51       ` Eric Abrahamsen
@ 2020-04-17 15:38         ` David Engster
  2020-04-17 16:35           ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: David Engster @ 2020-04-17 15:38 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: ding

> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> On Apr 17 2020, Gijs Hillenius wrote:
>>
>>> Yes, I do that too. And when I forget, I /have/ to quit Gnus when I wake
>>> up the laptop, or else hitting g will make Gnus just hang out there for
>>> a long time before it returns empty handed.
>>
>> Does it work to close the servers (gnus-close-all-servers)?
>
> I use "z" sort of compulsively, any time I haven't touched Gnus for a
> while. (I've also put all my nntp groups at level 5 and all my nnimap
> groups at level 3, so I can do "3 g" and not worry about it.)
>
> "z" usually works, but the point of this thread was that, when I switch
> network connections, it often *doesn't*, and neither does restarting
> Gnus. I've got to kill all of Emacs.

This is weird.

I see you're using current master. Does this also happen with current
Emacs 27 pretest?

I usually do not even close severs or suspend Gnus after a network
switch. I just hit 'g', and if Gnus hangs I lean on Ctrl+g until it
aborts and then hit 'g' again, which is usually enough to re-open the
servers.

I've already thought of using DBus to automate closing of servers on
network change, but never bothered to actually do it because it works
well enough...

-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-17 15:38         ` David Engster
@ 2020-04-17 16:35           ` Eric Abrahamsen
  0 siblings, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-17 16:35 UTC (permalink / raw)
  To: ding

David Engster <deng@randomsample.de> writes:

>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>
>>> On Apr 17 2020, Gijs Hillenius wrote:
>>>
>>>> Yes, I do that too. And when I forget, I /have/ to quit Gnus when I wake
>>>> up the laptop, or else hitting g will make Gnus just hang out there for
>>>> a long time before it returns empty handed.
>>>
>>> Does it work to close the servers (gnus-close-all-servers)?
>>
>> I use "z" sort of compulsively, any time I haven't touched Gnus for a
>> while. (I've also put all my nntp groups at level 5 and all my nnimap
>> groups at level 3, so I can do "3 g" and not worry about it.)
>>
>> "z" usually works, but the point of this thread was that, when I switch
>> network connections, it often *doesn't*, and neither does restarting
>> Gnus. I've got to kill all of Emacs.
>
> This is weird.
>
> I see you're using current master. Does this also happen with current
> Emacs 27 pretest?

I haven't tried switching back to Emacs 27, but it's been happening for
ages, since master *was* 27, so I wouldn't expect much difference.

> I usually do not even close severs or suspend Gnus after a network
> switch. I just hit 'g', and if Gnus hangs I lean on Ctrl+g until it
> aborts and then hit 'g' again, which is usually enough to re-open the
> servers.

Yeah, that's basically just the long way around for closing all servers
:)

> I've already thought of using DBus to automate closing of servers on
> network change, but never bothered to actually do it because it works
> well enough...

It works well enough for me, too, until it doesn't :( Maybe I'll open a
bug report and see if anyone's got any hints about debugging, it's
fairly reproducible.

E



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-16 17:37 new wifi connection = nntp timeout = Emacs restart? Eric Abrahamsen
  2020-04-17 11:46 ` Eric S Fraga
@ 2020-04-19  6:37 ` Christian Barthel
  2020-04-19 17:32   ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: Christian Barthel @ 2020-04-19  6:37 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Has anyone noticed that if you put your laptop to sleep while attached
> to one wifi network, then wake it up somewhere else and let it attach to
> a new network, nntp servers refuse to reconnect? In most cases, they
> refuse so hard that not only do I have to restart Gnus, I have to
> restart all of Emacs. I used to think it was my imagination, but it's
> happened too many times by now.
>
> Has anyone else seen this? What could be lingering in an Emacs session
> that would permanently prevent reconnection?

Huh, restarting?  I have seen similar behavior but I never had to
restart Emacs?

When switching the network or waking up from suspend, I usually
can't do `g' in Gnus.  It seems to stuck and I usually type `C-g'
then to abort, quit Gnus and start again (but I am not restarting
Emacs itself).

For me, it was not that much of a problem because most the time,
I am using the Gnus Agent and take my reader offline.  Usually, I
connect regularly and do a `J s` and then a `J j`.  After
switching the network or waking up, I do `J j` and `g` to fetch
new mail or news. 

I am using:
GNU Emacs 26.3 (build 1, amd64-portbld-freebsd12.1, GTK+ Version 3.24.10)

-- 
Christian Barthel <bch@online.de>


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19  6:37 ` Christian Barthel
@ 2020-04-19 17:32   ` Eric Abrahamsen
  2020-04-19 18:02     ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-19 17:32 UTC (permalink / raw)
  To: Christian Barthel; +Cc: ding

Christian Barthel <bch@online.de> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Has anyone noticed that if you put your laptop to sleep while attached
>> to one wifi network, then wake it up somewhere else and let it attach to
>> a new network, nntp servers refuse to reconnect? In most cases, they
>> refuse so hard that not only do I have to restart Gnus, I have to
>> restart all of Emacs. I used to think it was my imagination, but it's
>> happened too many times by now.
>>
>> Has anyone else seen this? What could be lingering in an Emacs session
>> that would permanently prevent reconnection?
>
> Huh, restarting?  I have seen similar behavior but I never had to
> restart Emacs?

Yeah, I used to assume I was hallucinating, but it's been going on for
too long now. The rest of what you describe below is perfectly "normal"
for Gnus, and the same as what we all experience, but this restarting
thing... Next time I switch networks (not all that often, these days)
I'll do some edebugging and try to open a more detailed bug report.

> When switching the network or waking up from suspend, I usually
> can't do `g' in Gnus.  It seems to stuck and I usually type `C-g'
> then to abort, quit Gnus and start again (but I am not restarting
> Emacs itself).
>
> For me, it was not that much of a problem because most the time,
> I am using the Gnus Agent and take my reader offline.  Usually, I
> connect regularly and do a `J s` and then a `J j`.  After
> switching the network or waking up, I do `J j` and `g` to fetch
> new mail or news. 
>
> I am using:
> GNU Emacs 26.3 (build 1, amd64-portbld-freebsd12.1, GTK+ Version 3.24.10)


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 17:32   ` Eric Abrahamsen
@ 2020-04-19 18:02     ` Robert Pluim
  2020-04-19 21:23       ` Eric Abrahamsen
                         ` (2 more replies)
  0 siblings, 3 replies; 67+ messages in thread
From: Robert Pluim @ 2020-04-19 18:02 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Christian Barthel, ding

>>>>> On Sun, 19 Apr 2020 10:32:03 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:
    Eric> Yeah, I used to assume I was hallucinating, but it's been going on for
    Eric> too long now. The rest of what you describe below is perfectly "normal"
    Eric> for Gnus, and the same as what we all experience, but this restarting
    Eric> thing... Next time I switch networks (not all that often, these days)
    Eric> I'll do some edebugging and try to open a more detailed bug report.

I see this too. Every time I try to look at it, itʼs an issue
somewhere deep in Emacs' networking code where itʼs trying to read
from the network and failing, but not failing enough that it gets an
error or a timeout. And then Real Life™ intervenes and I *have* to get
Gnus working again.

Iʼve tried turning on tcp-keepalives, but that doesnʼt help either.

Good luck, there are dragons in that part of the code :-)

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 18:02     ` Robert Pluim
@ 2020-04-19 21:23       ` Eric Abrahamsen
  2020-04-19 22:10       ` Eric Abrahamsen
  2020-04-30  5:26       ` Lars Ingebrigtsen
  2 siblings, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-19 21:23 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 19 Apr 2020 10:32:03 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:
>     Eric> Yeah, I used to assume I was hallucinating, but it's been going on for
>     Eric> too long now. The rest of what you describe below is perfectly "normal"
>     Eric> for Gnus, and the same as what we all experience, but this restarting
>     Eric> thing... Next time I switch networks (not all that often, these days)
>     Eric> I'll do some edebugging and try to open a more detailed bug report.
>
> I see this too.

Well that's sort of reassuring!

> Every time I try to look at it, itʼs an issue somewhere deep in Emacs'
> networking code where itʼs trying to read from the network and
> failing, but not failing enough that it gets an error or a timeout.
> And then Real Life™ intervenes and I *have* to get Gnus working again.

That's always the problem, Gnus is too mission critical. That's why I
made the gnus-mock package, which I wish more people would use for
hacking on Gnus!

> Iʼve tried turning on tcp-keepalives, but that doesnʼt help either.
>
> Good luck, there are dragons in that part of the code :-)

Oh I fully intend for someone else to solve the problem :) But I might
first try to set up a second wifi network in my apartment so I can test
more easily, and maybe see if netstat shows anything interesting.

Eric


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 18:02     ` Robert Pluim
  2020-04-19 21:23       ` Eric Abrahamsen
@ 2020-04-19 22:10       ` Eric Abrahamsen
  2020-04-20  4:54         ` Eric Abrahamsen
  2020-04-20  7:40         ` Andreas Schwab
  2020-04-30  5:26       ` Lars Ingebrigtsen
  2 siblings, 2 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-19 22:10 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sun, 19 Apr 2020 10:32:03 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:
>     Eric> Yeah, I used to assume I was hallucinating, but it's been going on for
>     Eric> too long now. The rest of what you describe below is perfectly "normal"
>     Eric> for Gnus, and the same as what we all experience, but this restarting
>     Eric> thing... Next time I switch networks (not all that often, these days)
>     Eric> I'll do some edebugging and try to open a more detailed bug report.
>
> I see this too. Every time I try to look at it, itʼs an issue
> somewhere deep in Emacs' networking code where itʼs trying to read
> from the network and failing, but not failing enough that it gets an
> error or a timeout. And then Real Life™ intervenes and I *have* to get
> Gnus working again.
>
> Iʼve tried turning on tcp-keepalives, but that doesnʼt help either.

I just started watching Emacs' nntp connections, and immediately noticed
that closing all servers ("z") and re-opening them ("g") does not kill
the previous connection, it just opens a new one, with it's own
keepalive timer.

If I kill Gnus, it kills all the open connections, but maybe there's
something about switching networks that prevents it from killing the
connections? And then we try to use a stale connection? I will test
more.

But doesn't it seem basically wrong that `gnus-close-server' on an nntp
server doesn't kill the network connection?


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 22:10       ` Eric Abrahamsen
@ 2020-04-20  4:54         ` Eric Abrahamsen
  2020-04-20  7:40         ` Andreas Schwab
  1 sibling, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-20  4:54 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Christian Barthel, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>>>>>> On Sun, 19 Apr 2020 10:32:03 -0700, Eric Abrahamsen
>> <eric@ericabrahamsen.net> said:
>>     Eric> Yeah, I used to assume I was hallucinating, but it's been going on for
>>     Eric> too long now. The rest of what you describe below is perfectly "normal"
>>     Eric> for Gnus, and the same as what we all experience, but this restarting
>>     Eric> thing... Next time I switch networks (not all that often, these days)
>>     Eric> I'll do some edebugging and try to open a more detailed bug report.
>>
>> I see this too. Every time I try to look at it, itʼs an issue
>> somewhere deep in Emacs' networking code where itʼs trying to read
>> from the network and failing, but not failing enough that it gets an
>> error or a timeout. And then Real Life™ intervenes and I *have* to get
>> Gnus working again.
>>
>> Iʼve tried turning on tcp-keepalives, but that doesnʼt help either.
>
> I just started watching Emacs' nntp connections, and immediately noticed
> that closing all servers ("z") and re-opening them ("g") does not kill
> the previous connection, it just opens a new one, with it's own
> keepalive timer.
>
> If I kill Gnus, it kills all the open connections, but maybe there's
> something about switching networks that prevents it from killing the
> connections? And then we try to use a stale connection? I will test
> more.
>
> But doesn't it seem basically wrong that `gnus-close-server' on an nntp
> server doesn't kill the network connection?

It's "z" suspending Gnus that doesn't work, "C" on the nntp server in
the *Server* buffer kills the connection correctly. Using "z" apparently
does not set the `nntp-server-buffer' correctly -- the
"(nntp-find-connection nntp-server-buffer)" call returns nil.

One step at a time...


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 22:10       ` Eric Abrahamsen
  2020-04-20  4:54         ` Eric Abrahamsen
@ 2020-04-20  7:40         ` Andreas Schwab
  2020-04-20 15:45           ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: Andreas Schwab @ 2020-04-20  7:40 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Robert Pluim, Christian Barthel, ding

On Apr 19 2020, Eric Abrahamsen wrote:

> I just started watching Emacs' nntp connections, and immediately noticed
> that closing all servers ("z")

Why do you think that gnus-group-suspend closes servers?
gnus-close-all-servers does.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-20  7:40         ` Andreas Schwab
@ 2020-04-20 15:45           ` Eric Abrahamsen
  2020-04-20 15:54             ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-20 15:45 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Robert Pluim, Christian Barthel, ding

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Apr 19 2020, Eric Abrahamsen wrote:
>
>> I just started watching Emacs' nntp connections, and immediately noticed
>> that closing all servers ("z")
>
> Why do you think that gnus-group-suspend closes servers?
> gnus-close-all-servers does.

Because gnus-group-suspend literally includes all the code in
gnus-close-all-servers...


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-20 15:45           ` Eric Abrahamsen
@ 2020-04-20 15:54             ` Robert Pluim
  2020-04-20 18:24               ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Robert Pluim @ 2020-04-20 15:54 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Andreas Schwab, Christian Barthel, ding

>>>>> On Mon, 20 Apr 2020 08:45:06 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:

    Eric> Andreas Schwab <schwab@linux-m68k.org> writes:
    >> On Apr 19 2020, Eric Abrahamsen wrote:
    >> 
    >>> I just started watching Emacs' nntp connections, and immediately noticed
    >>> that closing all servers ("z")
    >> 
    >> Why do you think that gnus-group-suspend closes servers?
    >> gnus-close-all-servers does.

    Eric> Because gnus-group-suspend literally includes all the code in
    Eric> gnus-close-all-servers...

It even says:

    ;; Closing all the backends is useful (for instance) when when the
    ;; IP addresses have changed and you need to reconnect.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-20 15:54             ` Robert Pluim
@ 2020-04-20 18:24               ` Eric Abrahamsen
  2020-04-21  8:36                 ` Alberto Luaces
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-20 18:24 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Andreas Schwab, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 20 Apr 2020 08:45:06 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:
>
>     Eric> Andreas Schwab <schwab@linux-m68k.org> writes:
>     >> On Apr 19 2020, Eric Abrahamsen wrote:
>     >>
>     >>> I just started watching Emacs' nntp connections, and immediately noticed
>     >>> that closing all servers ("z")
>     >>
>     >> Why do you think that gnus-group-suspend closes servers?
>     >> gnus-close-all-servers does.
>
>     Eric> Because gnus-group-suspend literally includes all the code in
>     Eric> gnus-close-all-servers...
>
> It even says:
>
>     ;; Closing all the backends is useful (for instance) when when the
>     ;; IP addresses have changed and you need to reconnect.

Okay, progress! Glad I'm inflicting this on all of you in the group,
rather than embarrassing myself in a bug report.

First of all, refreshing Gnus after moving to a new wifi network showed
the nntp connection going from this:

tcp 0 0 192.168.1.39:42194 159.69.161.202:nntp users:(("emacs",pid=143327,fd=18)) timer:(keepalive,94min,0)

to this:

tcp 0 1558 192.168.1.39:42194 159.69.161.202:nntp users:(("emacs",id=143327,fd=18)) timer:(persist,4.800ms,3)

Dunno if that means anything!

But left-behind nntp connections don't seem to be the source of the
problem: Once Gnus fails to reconnect, and I hit "g" again, all the old
connections are killed. (FWIW, I'm still pretty sure it's a bug that
gnus-suspend and close-servers don't kill the nntp connection, there
should never be more than one per server.) So my original hunch was
wrong, as most of my hunches seem to be.

Edebugging `nntp-open-connection', it turns out the condition-case, with
nnheader-report in the error clause, was swallowing real errors -- it
never occurred to me to ask the nntp server for its "report string". The
first error I saw was:

nntp-with-open-group-function: Wrong type argument: stringp, nil

which is my favorite Gnus error. i'm not sure where that came from. The
real problem seems to be:

(error "news.gmane.io/nntp Temporary failure in name resol...")

And I think that's our culprit! The DNS lookup fails, and continues to
fail until I restart Emacs. So I'm assuming Emacs has some sort of dns
caching going on, or something, that presumably we could flush if we
wanted to.

I'm going to leave this here for a day or two, then open a proper bug
report.

E


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-20 18:24               ` Eric Abrahamsen
@ 2020-04-21  8:36                 ` Alberto Luaces
  2020-04-21 15:53                   ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Alberto Luaces @ 2020-04-21  8:36 UTC (permalink / raw)
  To: ding

Eric Abrahamsen writes:

> tcp 0 0 192.168.1.39:42194 159.69.161.202:nntp users:(("emacs",pid=143327,fd=18)) timer:(keepalive,94min,0)

Eric, what tool is that? lsof?

Thanks!

-- 
Alberto



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-21  8:36                 ` Alberto Luaces
@ 2020-04-21 15:53                   ` Eric Abrahamsen
  2020-04-22  7:37                     ` Alberto Luaces
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-21 15:53 UTC (permalink / raw)
  To: Alberto Luaces; +Cc: ding

Alberto Luaces <aluaces@udc.es> writes:

> Eric Abrahamsen writes:
>
>> tcp 0 0 192.168.1.39:42194 159.69.161.202:nntp
>> users:(("emacs",pid=143327,fd=18)) timer:(keepalive,94min,0)
>
> Eric, what tool is that? lsof?

That's the "ss" utility, which is apparently what we're supposed to be
using on Arch linux -- I can hardly keep up! I went looking for netstat,
and eventually found this. It's all the information you need, any way...


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-21 15:53                   ` Eric Abrahamsen
@ 2020-04-22  7:37                     ` Alberto Luaces
  2020-04-22  8:28                       ` Alberto Luaces
  0 siblings, 1 reply; 67+ messages in thread
From: Alberto Luaces @ 2020-04-22  7:37 UTC (permalink / raw)
  To: ding

Eric Abrahamsen writes:

> Alberto Luaces <aluaces@udc.es> writes:
>
>> Eric Abrahamsen writes:
>>
>>> tcp 0 0 192.168.1.39:42194 159.69.161.202:nntp
>>> users:(("emacs",pid=143327,fd=18)) timer:(keepalive,94min,0)
>>
>> Eric, what tool is that? lsof?
>
> That's the "ss" utility, which is apparently what we're supposed to be
> using on Arch linux -- I can hardly keep up! I went looking for netstat,
> and eventually found this. It's all the information you need, any way...
>

Thanks, indeed I use it always since I read it was the successor of
netstat, but I'm used to write "ss -untap" and I don't know how to get
the timeouts or the waiting time of each socket as you did.  That's why
I didn't even recognize it from the output.

Time to investigate more...
-- 
Alberto



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-22  7:37                     ` Alberto Luaces
@ 2020-04-22  8:28                       ` Alberto Luaces
  0 siblings, 0 replies; 67+ messages in thread
From: Alberto Luaces @ 2020-04-22  8:28 UTC (permalink / raw)
  To: ding

Alberto Luaces writes:

> Time to investigate more...

Got it.  It is the "-o" option, so for me now it is "ss -untapo".

-- 
Alberto



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-19 18:02     ` Robert Pluim
  2020-04-19 21:23       ` Eric Abrahamsen
  2020-04-19 22:10       ` Eric Abrahamsen
@ 2020-04-30  5:26       ` Lars Ingebrigtsen
  2020-04-30 17:34         ` Eric Abrahamsen
  2020-04-30 17:38         ` Eric Abrahamsen
  2 siblings, 2 replies; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30  5:26 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> I see this too. Every time I try to look at it, itʼs an issue
> somewhere deep in Emacs' networking code where itʼs trying to read
> from the network and failing, but not failing enough that it gets an
> error or a timeout. And then Real Life™ intervenes and I *have* to get
> Gnus working again.

Yeah, it's a really annoying problem, and unfortunately there is no
general solution we can use.  Sometimes network connections just "go
away", and when you try to use a long-lived connection, you just don't
get a response back.

This is commonly due to wifi (IP changes or not), but I've also
experienced it with some horrible routers.

The problem is that there is no one-solution-fits-all for all the
network protocols that Emacs supports.

IRC has this solved -- they use keepalive packets, and if Emacs doesn't
get one from the server, it reconnects.  Easy peasy.

NNTP and IMAP doesn't have anything like that, so nntp.el and nnimap.el
should be clever and reconnect if we send a command and get no response
back.

However -- I've seen IMAP servers that take half a minute to give a
response to a simple RESYNC command.  (Rearranging its index server
side, I think it was.)

So you can't just put a 1-second timeout on all commands, either.

But I've been pondering whether it would make sense for IMAP to always
send an NOOP command before any other commands, because IMAP is a
streaming protocol.

So instead of

1 QRESYNC foo

we'd send

1 NOOP
2 QRESYNC foo

and if we don't get a response to the NOOP within a very short time
(even if the QRESYNC takes a long time), then we know that something is
wrong and we should reconnect.

NNTP has no such a thing, I think...

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30  5:26       ` Lars Ingebrigtsen
@ 2020-04-30 17:34         ` Eric Abrahamsen
  2020-04-30 21:49           ` Lars Ingebrigtsen
  2020-04-30 17:38         ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 17:34 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, Christian Barthel, ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I see this too. Every time I try to look at it, itʼs an issue
>> somewhere deep in Emacs' networking code where itʼs trying to read
>> from the network and failing, but not failing enough that it gets an
>> error or a timeout. And then Real Life™ intervenes and I *have* to get
>> Gnus working again.
>
> Yeah, it's a really annoying problem, and unfortunately there is no
> general solution we can use.  Sometimes network connections just "go
> away", and when you try to use a long-lived connection, you just don't
> get a response back.

Thanks for this background! Later I opened bug#40748, and in doing so
discovered that the actual problem was in the DNS lookup:

(error "news.gmane.io/nntp Temporary failure in name resol...")

Or at least, it was being reported as such.

Does that change your assessment at all? Or is it what you'd expect?

> This is commonly due to wifi (IP changes or not), but I've also
> experienced it with some horrible routers.
>
> The problem is that there is no one-solution-fits-all for all the
> network protocols that Emacs supports.
>
> IRC has this solved -- they use keepalive packets, and if Emacs doesn't
> get one from the server, it reconnects.  Easy peasy.
>
> NNTP and IMAP doesn't have anything like that, so nntp.el and nnimap.el
> should be clever and reconnect if we send a command and get no response
> back.
>
> However -- I've seen IMAP servers that take half a minute to give a
> response to a simple RESYNC command.  (Rearranging its index server
> side, I think it was.)
>
> So you can't just put a 1-second timeout on all commands, either.
>
> But I've been pondering whether it would make sense for IMAP to always
> send an NOOP command before any other commands, because IMAP is a
> streaming protocol.
>
> So instead of
>
> 1 QRESYNC foo
>
> we'd send
>
> 1 NOOP
> 2 QRESYNC foo
>
> and if we don't get a response to the NOOP within a very short time
> (even if the QRESYNC takes a long time), then we know that something is
> wrong and we should reconnect.
>
> NNTP has no such a thing, I think...


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30  5:26       ` Lars Ingebrigtsen
  2020-04-30 17:34         ` Eric Abrahamsen
@ 2020-04-30 17:38         ` Eric Abrahamsen
  2020-04-30 21:51           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 17:38 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, Christian Barthel, ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I see this too. Every time I try to look at it, itʼs an issue
>> somewhere deep in Emacs' networking code where itʼs trying to read
>> from the network and failing, but not failing enough that it gets an
>> error or a timeout. And then Real Life™ intervenes and I *have* to get
>> Gnus working again.
>
> Yeah, it's a really annoying problem, and unfortunately there is no
> general solution we can use.  Sometimes network connections just "go
> away", and when you try to use a long-lived connection, you just don't
> get a response back.
>
> This is commonly due to wifi (IP changes or not), but I've also
> experienced it with some horrible routers.
>
> The problem is that there is no one-solution-fits-all for all the
> network protocols that Emacs supports.
>
> IRC has this solved -- they use keepalive packets, and if Emacs doesn't
> get one from the server, it reconnects.  Easy peasy.
>
> NNTP and IMAP doesn't have anything like that, so nntp.el and nnimap.el
> should be clever and reconnect if we send a command and get no response
> back.
>
> However -- I've seen IMAP servers that take half a minute to give a
> response to a simple RESYNC command.  (Rearranging its index server
> side, I think it was.)
>
> So you can't just put a 1-second timeout on all commands, either.
>
> But I've been pondering whether it would make sense for IMAP to always
> send an NOOP command before any other commands, because IMAP is a
> streaming protocol.
>
> So instead of
>
> 1 QRESYNC foo
>
> we'd send
>
> 1 NOOP
> 2 QRESYNC foo

I suppose this could also be sent every ten minutes or so on an idle
timer, quietly closing the imap connection if we don't get a response.
Ie faking a keepalive. That could ultimately reduce network traffic, right?


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 17:34         ` Eric Abrahamsen
@ 2020-04-30 21:49           ` Lars Ingebrigtsen
  2020-04-30 22:11             ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 21:49 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Robert Pluim, Christian Barthel, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Thanks for this background! Later I opened bug#40748, and in doing so
> discovered that the actual problem was in the DNS lookup:
>
> (error "news.gmane.io/nntp Temporary failure in name resol...")
>
> Or at least, it was being reported as such.
>
> Does that change your assessment at all? Or is it what you'd expect?

A DNS lookup failing should never make Gnus hang, so that's pretty
surprising.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 17:38         ` Eric Abrahamsen
@ 2020-04-30 21:51           ` Lars Ingebrigtsen
  2020-04-30 22:26             ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 21:51 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Robert Pluim, Christian Barthel, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I suppose this could also be sent every ten minutes or so on an idle
> timer, quietly closing the imap connection if we don't get a response.
> Ie faking a keepalive. That could ultimately reduce network traffic, right?

nnimap.el already sends out the NOOP command periodically (in
nnimap-keepalive), but it doesn't do anything if that fails (or gets no
response).

It should, but that's a somewhat orthogonal issue to the "I woke my
laptup up and now 'g' hangs" thing that's common.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 21:49           ` Lars Ingebrigtsen
@ 2020-04-30 22:11             ` Eric Abrahamsen
  2020-05-04 12:53               ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 22:11 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, Christian Barthel, ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Thanks for this background! Later I opened bug#40748, and in doing so
>> discovered that the actual problem was in the DNS lookup:
>>
>> (error "news.gmane.io/nntp Temporary failure in name resol...")
>>
>> Or at least, it was being reported as such.
>>
>> Does that change your assessment at all? Or is it what you'd expect?
>
> A DNS lookup failing should never make Gnus hang, so that's pretty
> surprising.

This error comes in `nntp-open-connection', as the condition-case error
caught from `open-network-stream'. I only just realized that's a lisp
function, but looking at it we should be using `make-network-process'.

The DNS lookup isn't hanging (or hanging Gnus) so much as it is taking a
long time to fail, and then _continuing to fail until Emacs is
restarted_.

So I'm hoping this is unrelated to Gnus, and actually a problem with
Emacs caching the DNS server it's trying to use, which is later
unavailable on a new network. (But then why would I only see this with
Gnus nntp connections? On the other hand, all my nnimap connections are
localhost, nntp is my only non-local Gnus network connection.)


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 21:51           ` Lars Ingebrigtsen
@ 2020-04-30 22:26             ` Eric Abrahamsen
  2020-04-30 22:28               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 22:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, Christian Barthel, ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I suppose this could also be sent every ten minutes or so on an idle
>> timer, quietly closing the imap connection if we don't get a response.
>> Ie faking a keepalive. That could ultimately reduce network traffic, right?
>
> nnimap.el already sends out the NOOP command periodically (in
> nnimap-keepalive), but it doesn't do anything if that fails (or gets no
> response).

Oh, I actually knew that, but had forgotten. If we're already doing
that, what do you think about checking for a response (minimal wait
time) and then closing the connection? Perhaps behind a custom option?


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 22:26             ` Eric Abrahamsen
@ 2020-04-30 22:28               ` Lars Ingebrigtsen
  2020-04-30 22:39                 ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 22:28 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Robert Pluim, Christian Barthel, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Oh, I actually knew that, but had forgotten. If we're already doing
> that, what do you think about checking for a response (minimal wait
> time) and then closing the connection? Perhaps behind a custom option?

Yes, that would be good.  But we basically need the same machinery for
the general case, I think?

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 22:28               ` Lars Ingebrigtsen
@ 2020-04-30 22:39                 ` Eric Abrahamsen
  2020-04-30 22:55                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 22:39 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Oh, I actually knew that, but had forgotten. If we're already doing
>> that, what do you think about checking for a response (minimal wait
>> time) and then closing the connection? Perhaps behind a custom option?
>
> Yes, that would be good.  But we basically need the same machinery for
> the general case, I think?

But we don't actually have a general case, do we -- as you noted, nntp
doesn't have a NOOP equivalent. Is there something else we can use?


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 22:39                 ` Eric Abrahamsen
@ 2020-04-30 22:55                   ` Lars Ingebrigtsen
  2020-04-30 23:13                     ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 22:55 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> Yes, that would be good.  But we basically need the same machinery for
>> the general case, I think?
>
> But we don't actually have a general case, do we -- as you noted, nntp
> doesn't have a NOOP equivalent. Is there something else we can use?

Not that general.  :-)  I mean -- for nnimap.el, and the "general" thing
is "there should be a timeout on commands".

So an nnimap-keepalive timeout should use the same mechanism as the
proposed NOOP-command-prepend mechanism.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 22:55                   ` Lars Ingebrigtsen
@ 2020-04-30 23:13                     ` Eric Abrahamsen
  2020-04-30 23:23                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-04-30 23:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>>> Yes, that would be good.  But we basically need the same machinery for
>>> the general case, I think?
>>
>> But we don't actually have a general case, do we -- as you noted, nntp
>> doesn't have a NOOP equivalent. Is there something else we can use?
>
> Not that general.  :-)  I mean -- for nnimap.el, and the "general" thing
> is "there should be a timeout on commands".
>
> So an nnimap-keepalive timeout should use the same mechanism as the
> proposed NOOP-command-prepend mechanism.

Oh I see. I was assuming that adding connection closing to
nnimap-keepalive would make the NOOP-prepend mechanism unnecessary.
Seems like we'd only need one of the two, so long as whatever it was
came with teeth (closing the connection).


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 23:13                     ` Eric Abrahamsen
@ 2020-04-30 23:23                       ` Lars Ingebrigtsen
  2020-05-01  9:46                         ` David Engster
  2020-05-01 18:06                         ` Eric Abrahamsen
  0 siblings, 2 replies; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-04-30 23:23 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Oh I see. I was assuming that adding connection closing to
> nnimap-keepalive would make the NOOP-prepend mechanism unnecessary.
> Seems like we'd only need one of the two, so long as whatever it was
> came with teeth (closing the connection).

nnimap-keepalive-connection-drop doesn't help with the common "I just
woke my laptop up and now `g' hangs" situation.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 23:23                       ` Lars Ingebrigtsen
@ 2020-05-01  9:46                         ` David Engster
  2020-05-01 10:35                           ` David Engster
  2020-05-01 18:06                         ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: David Engster @ 2020-05-01  9:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eric Abrahamsen, ding

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Oh I see. I was assuming that adding connection closing to
>> nnimap-keepalive would make the NOOP-prepend mechanism unnecessary.
>> Seems like we'd only need one of the two, so long as whatever it was
>> came with teeth (closing the connection).
>
> nnimap-keepalive-connection-drop doesn't help with the common "I just
> woke my laptop up and now `g' hangs" situation.

Another possiblity: Instead of trying to detect dead connections, let's
try to get notified when networking has changed and react accordingly. I
think this is what those "apps" do on mobiles?

On GNU/Linux my guess is the lowest common denominator nowadays for
doing stuff like this is systemd and DBus?

It's actually surprisingly easy to do this in Emacs if you know what to
fill in:

(require 'dbus)

(defun my-dbus-handler (interface-name values novals)
  (message "Change registered on: %s" interface-name)
  (message "Changed values: %s" (prin1-to-string values))
  (message "Changed without value: %s" (prin1-to-string novals)))

(dbus-register-signal :system
		      "org.freedesktop.systemd1"
		      "/org/freedesktop/systemd1/unit/networking_2eservice"
		      "org.freedesktop.DBus.Properties"		      
		      "PropertiesChanged"
		      'my-dbus-handler)

Now do "systemctl restart networking.service" and watch all these spiffy
messages. This is on Debian 10, I'm hoping it's at least similar on
other systems? You can inspect this stuff with 'busctl', for instance:

busctl tree org.freedesktop.systemd1

busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/networking_2eservice

I have no idea if this is "The Best Way", probably not. Also, I'm not
seeing anything on resuming, but maybe there's another path for that...?
Or maybe I'm not letting my laptop sleep long enough?

-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-01  9:46                         ` David Engster
@ 2020-05-01 10:35                           ` David Engster
  2020-05-01 17:29                             ` Eric Abrahamsen
  2020-08-21 20:47                             ` Eric Abrahamsen
  0 siblings, 2 replies; 67+ messages in thread
From: David Engster @ 2020-05-01 10:35 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eric Abrahamsen, ding

> I have no idea if this is "The Best Way", probably not. Also, I'm not
> seeing anything on resuming, but maybe there's another path for that...?
> Or maybe I'm not letting my laptop sleep long enough?

So at least for sleeping/waking this seems to be the easiest way:

(require 'dbus)

(defun 'my-go-to-sleep-handler (sleep-start)
  ;; sleep-start will be 't' before sleeping and 'nil' on wakeup?
  (when sleep-start
     (gnus-close-all-servers)))

(dbus-register-signal :system
		      "org.freedesktop.login1"
		      "/org/freedesktop/login1"
		      "org.freedesktop.login1.Manager"
		      "PrepareForSleep"
		      'my-go-to-sleep-handler)

-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-01 10:35                           ` David Engster
@ 2020-05-01 17:29                             ` Eric Abrahamsen
  2020-05-01 20:51                               ` David Engster
  2020-08-21 20:47                             ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-01 17:29 UTC (permalink / raw)
  To: David Engster; +Cc: Lars Ingebrigtsen, ding

David Engster <deng@randomsample.de> writes:

>> I have no idea if this is "The Best Way", probably not. Also, I'm not
>> seeing anything on resuming, but maybe there's another path for that...?
>> Or maybe I'm not letting my laptop sleep long enough?
>
> So at least for sleeping/waking this seems to be the easiest way:
>
> (require 'dbus)
>
> (defun 'my-go-to-sleep-handler (sleep-start)
>   ;; sleep-start will be 't' before sleeping and 'nil' on wakeup?
>   (when sleep-start
>      (gnus-close-all-servers)))
>
> (dbus-register-signal :system
> 		      "org.freedesktop.login1"
> 		      "/org/freedesktop/login1"
> 		      "org.freedesktop.login1.Manager"
> 		      "PrepareForSleep"
> 		      'my-go-to-sleep-handler)
>
> -David

Hey, that's pretty handy! Just FYI, the function name is quoted
unnecessarily, and sleep-start is actually nil when it's going to sleep,
who knows why.

Particularly handy since, in all my years of using dbus machines, I have
never managed to write a dbus rule that did anything other than fail
silently. This is useful.

Thanks,
Eric


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 23:23                       ` Lars Ingebrigtsen
  2020-05-01  9:46                         ` David Engster
@ 2020-05-01 18:06                         ` Eric Abrahamsen
  1 sibling, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-01 18:06 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Oh I see. I was assuming that adding connection closing to
>> nnimap-keepalive would make the NOOP-prepend mechanism unnecessary.
>> Seems like we'd only need one of the two, so long as whatever it was
>> came with teeth (closing the connection).
>
> nnimap-keepalive-connection-drop doesn't help with the common "I just
> woke my laptop up and now `g' hangs" situation.

No, I guess not -- unless you're lucky enough that the keepalive timer
was about to fire already.

Anyway, if you think having both is a better idea, I can work on it.

Eric


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-01 17:29                             ` Eric Abrahamsen
@ 2020-05-01 20:51                               ` David Engster
  2020-05-02  0:33                                 ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: David Engster @ 2020-05-01 20:51 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, ding

> Hey, that's pretty handy! Just FYI, the function name is quoted
> unnecessarily

Oops...

> and sleep-start is actually nil when it's going to sleep,
> who knows why.

Uhm, not for me. I just tested again to make sure. On sleep it is 't',
on wakup it is nil. This is also the documented behavior:

  The PrepareForShutdown() resp. PrepareForSleep() signals are sent right
  before (with the argument True) and after (with the argument False) the
  system goes down for reboot/poweroff, resp. suspend/hibernate.

https://www.freedesktop.org/wiki/Software/systemd/logind/

> Particularly handy since, in all my years of using dbus machines, I have
> never managed to write a dbus rule that did anything other than fail
> silently. This is useful.

You can actually do pretty nifty things with DBus, but it's... well,
let's say: convoluted. But Michael Albinus has really done a great job
for the Emacs interface, it's really simple to use and well documented.

As for detecting networking changes, I don't think it is possible to do
this with the systemd networking.service only, you'll also need
NetworkManager. I tried NetworkManager years ago and it was... really
not good. I just tried it again today and was happily surprised how well
it works nowadays. Some things just need time.

So NetworkManager will tell you everything you need to know via DBus:

https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.html

So from that I guess checking for changes on 'State' makes the most
sense?

(defun my-network-state-handler (name change-vals change-novals)
  (let ((state (assoc "State" change-vals)))
    (when state
      (message "New State: %s" (caadr state)))))

(dbus-register-signal :system
		      "org.freedesktop.Networkmanager"
		      "/org/freedesktop/NetworkManager"
		      "org.freedesktop.DBus.Properties"		      
		      "PropertiesChanged"
		      'my-network-state-handler)

So if you evaluate this and put your network down, you should see
something like

New State: 30
New State: 20

And if you put it up again:

New State: 40
New State: 50
New State: 60
New State: 70

The numbers are explained here:

https://developer.gnome.org/NetworkManager/stable/nm-dbus-types.html#NMState

So from that I guess we should just call gnus-close-all-servers for
state=30:

  Network connections are being cleaned up. The applications should tear
  down their network sessions.

-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-01 20:51                               ` David Engster
@ 2020-05-02  0:33                                 ` Eric Abrahamsen
  2020-05-02 10:20                                   ` David Engster
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-02  0:33 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: ding

David Engster <deng@randomsample.de> writes:

>> Hey, that's pretty handy! Just FYI, the function name is quoted
>> unnecessarily
>
> Oops...
>
>> and sleep-start is actually nil when it's going to sleep,
>> who knows why.
>
> Uhm, not for me. I just tested again to make sure. On sleep it is 't',
> on wakup it is nil. This is also the documented behavior:

Huh, the first time I tried it, it only seemed to fire on wakeup (giving
me a nil). And I forgot that `gnus-close-all-servers' doesn't actually
redisplay the *Server* buffer, so was confusing myself.

On wakeup all my nnimap servers were denied, but I'm sure it's just a
matter of messing with it sufficiently.


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-02  0:33                                 ` Eric Abrahamsen
@ 2020-05-02 10:20                                   ` David Engster
  2020-05-02 15:13                                     ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: David Engster @ 2020-05-02 10:20 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, ding

> David Engster <deng@randomsample.de> writes:
>
>>> Hey, that's pretty handy! Just FYI, the function name is quoted
>>> unnecessarily
>>
>> Oops...
>>
>>> and sleep-start is actually nil when it's going to sleep,
>>> who knows why.
>>
>> Uhm, not for me. I just tested again to make sure. On sleep it is 't',
>> on wakup it is nil. This is also the documented behavior:
>
> Huh, the first time I tried it, it only seemed to fire on wakeup (giving
> me a nil). And I forgot that `gnus-close-all-servers' doesn't actually
> redisplay the *Server* buffer, so was confusing myself.

Yes, I noticed this as well. There's `gnus-close-server' and there's
`gnus-server-close-server', and the latter does a bit more, like setting
the server's status to 'closed' and updating the server buffer. I don't
think it matters for the connection, though, it's just confusing.

> On wakeup all my nnimap servers were denied, but I'm sure it's just a
> matter of messing with it sufficiently.

I'll try this for a while and see how it goes. I think this could be
expanded, like for instance checking for 'State' of NetworkManager
before trying to open servers that require an active connection.

For the record, this is what I'm using now:

(require 'dbus)
(defun my-go-to-sleep-handler (sleep-start)
  (when sleep-start
    (message "Gnus: Machine going to sleep, closing connections")
    (gnus-close-all-servers)))

(dbus-register-signal :system
		      "org.freedesktop.login1"
		      "/org/freedesktop/login1"
		      "org.freedesktop.login1.Manager"
		      "PrepareForSleep"
		      'my-go-to-sleep-handler)

(defun my-network-state-handler (name change-vals change-novals)
  (let ((state (assoc "State" change-vals)))
    (when (and state
	       (= (caadr state) 30))
      (message "Gnus: Networking going down, closing servers.")
      (gnus-close-all-servers))))

(dbus-register-signal :system
		      "org.freedesktop.Networkmanager"
		      "/org/freedesktop/NetworkManager"
		      "org.freedesktop.DBus.Properties"		      
		      "PropertiesChanged"
		      'my-network-state-handler)


-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-02 10:20                                   ` David Engster
@ 2020-05-02 15:13                                     ` Eric Abrahamsen
  2020-05-02 16:50                                       ` David Engster
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-02 15:13 UTC (permalink / raw)
  To: David Engster; +Cc: Lars Ingebrigtsen, ding

David Engster <deng@randomsample.de> writes:

>> David Engster <deng@randomsample.de> writes:
>>
>>>> Hey, that's pretty handy! Just FYI, the function name is quoted
>>>> unnecessarily
>>>
>>> Oops...
>>>
>>>> and sleep-start is actually nil when it's going to sleep,
>>>> who knows why.
>>>
>>> Uhm, not for me. I just tested again to make sure. On sleep it is 't',
>>> on wakup it is nil. This is also the documented behavior:
>>
>> Huh, the first time I tried it, it only seemed to fire on wakeup (giving
>> me a nil). And I forgot that `gnus-close-all-servers' doesn't actually
>> redisplay the *Server* buffer, so was confusing myself.
>
> Yes, I noticed this as well. There's `gnus-close-server' and there's
> `gnus-server-close-server', and the latter does a bit more, like setting
> the server's status to 'closed' and updating the server buffer. I don't
> think it matters for the connection, though, it's just confusing.

Right.

>> On wakeup all my nnimap servers were denied, but I'm sure it's just a
>> matter of messing with it sufficiently.
>
> I'll try this for a while and see how it goes. I think this could be
> expanded, like for instance checking for 'State' of NetworkManager
> before trying to open servers that require an active connection.
>
> For the record, this is what I'm using now:
>
> (require 'dbus)
> (defun my-go-to-sleep-handler (sleep-start)
>   (when sleep-start
>     (message "Gnus: Machine going to sleep, closing connections")
>     (gnus-close-all-servers)))
>
> (dbus-register-signal :system
> 		      "org.freedesktop.login1"
> 		      "/org/freedesktop/login1"
> 		      "org.freedesktop.login1.Manager"
> 		      "PrepareForSleep"
> 		      'my-go-to-sleep-handler)
>
> (defun my-network-state-handler (name change-vals change-novals)
>   (let ((state (assoc "State" change-vals)))
>     (when (and state
> 	       (= (caadr state) 30))
>       (message "Gnus: Networking going down, closing servers.")
>       (gnus-close-all-servers))))
>
> (dbus-register-signal :system
> 		      "org.freedesktop.Networkmanager"
> 		      "/org/freedesktop/NetworkManager"
> 		      "org.freedesktop.DBus.Properties"		      
> 		      "PropertiesChanged"
> 		      'my-network-state-handler)

But this requires installing the NetworkManager package, right? Which
I've been happily doing without.

I wonder what percentage of Gnus users are on dbus-enabled systems... I
don't suppose it's worth trying to make something built-in for them.


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-02 15:13                                     ` Eric Abrahamsen
@ 2020-05-02 16:50                                       ` David Engster
  2020-05-02 19:07                                         ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: David Engster @ 2020-05-02 16:50 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, ding

> But this requires installing the NetworkManager package, right?

For detecting network changes, yes.

> Which I've been happily doing without.

Me too, until yesterday, but not happily. Dealing with WiFi through 'iw'
and editing /etc/network/interfaces is not a success story, IMHO.

> I wonder what percentage of Gnus users are on dbus-enabled systems...

On GNU/Linux: high percentage. It's very hard to remove DBus from a
modern distribution. Unless you're working on a tty or only use
'startx', it's most probably running.

> I don't suppose it's worth trying to make something built-in for them.

I think it does no harm to have something like this as long as it
doesn't bother people who don't want/have it. I'm sure Lars will
eventually come up with the perfect method to detect stale TCP
connections, but even then I'd consider this useful.

-David


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-02 16:50                                       ` David Engster
@ 2020-05-02 19:07                                         ` Eric Abrahamsen
  2020-05-19 13:23                                           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-02 19:07 UTC (permalink / raw)
  To: David Engster; +Cc: Lars Ingebrigtsen, ding

David Engster <deng@randomsample.de> writes:

>> But this requires installing the NetworkManager package, right?
>
> For detecting network changes, yes.
>
>> Which I've been happily doing without.
>
> Me too, until yesterday, but not happily. Dealing with WiFi through 'iw'
> and editing /etc/network/interfaces is not a success story, IMHO.

I've had pretty good luck with netctl and it's wifi-menu program.

>> I wonder what percentage of Gnus users are on dbus-enabled systems...
>
> On GNU/Linux: high percentage. It's very hard to remove DBus from a
> modern distribution. Unless you're working on a tty or only use
> 'startx', it's most probably running.
>
>> I don't suppose it's worth trying to make something built-in for them.
>
> I think it does no harm to have something like this as long as it
> doesn't bother people who don't want/have it. I'm sure Lars will
> eventually come up with the perfect method to detect stale TCP
> connections, but even then I'd consider this useful.

I've already had an off-list vote in the negative! But of course this
would come protected behind a custom option. If we even think there's
any point at all.

If Lars had a magic bullet, I think he would have used it by now...


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-04-30 22:11             ` Eric Abrahamsen
@ 2020-05-04 12:53               ` Robert Pluim
  2020-05-04 13:13                 ` Andreas Schwab
                                   ` (2 more replies)
  0 siblings, 3 replies; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 12:53 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Thu, 30 Apr 2020 15:11:38 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:

    >> A DNS lookup failing should never make Gnus hang, so that's pretty
    >> surprising.

    Eric> This error comes in `nntp-open-connection', as the condition-case error
    Eric> caught from `open-network-stream'. I only just realized that's a lisp
    Eric> function, but looking at it we should be using `make-network-process'.

Iʼd rather you didnʼt move in that direction. 'make-network-process'
is low-level plumbing, 'open-network-stream' is what user code should
be using. What feature is 'open-network-stream' missing for you?

    Eric> The DNS lookup isn't hanging (or hanging Gnus) so much as it is taking a
    Eric> long time to fail, and then _continuing to fail until Emacs is
    Eric> restarted_.

    Eric> So I'm hoping this is unrelated to Gnus, and actually a problem with
    Eric> Emacs caching the DNS server it's trying to use, which is later
    Eric> unavailable on a new network. (But then why would I only see this with
    Eric> Gnus nntp connections? On the other hand, all my nnimap connections are
    Eric> localhost, nntp is my only non-local Gnus network connection.)

Emacs doesnʼt directly address the DNS server, it uses getaddrinfo or
getaddrinfo_a, which means any caching going on is in the IP
stack. Although given that this is being seen on GNU/Linux and macOS,
it may well be emacs at fault.

Also, I see this when coming out of sleep and connecting to the same
wifi network, with the same IP, and the same DNS server, which I guess
implicates Emacs more.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 12:53               ` Robert Pluim
@ 2020-05-04 13:13                 ` Andreas Schwab
  2020-05-04 13:33                   ` Robert Pluim
  2020-05-04 14:51                 ` Lars Ingebrigtsen
  2020-05-04 15:38                 ` Eric Abrahamsen
  2 siblings, 1 reply; 67+ messages in thread
From: Andreas Schwab @ 2020-05-04 13:13 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

On Mai 04 2020, Robert Pluim wrote:

> Also, I see this when coming out of sleep and connecting to the same
> wifi network, with the same IP, and the same DNS server, which I guess
> implicates Emacs more.

Perhaps you are just running into some conntrack timeout.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 13:13                 ` Andreas Schwab
@ 2020-05-04 13:33                   ` Robert Pluim
  2020-05-04 14:35                     ` Andreas Schwab
  0 siblings, 1 reply; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 13:33 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 15:13:38 +0200, Andreas Schwab <schwab@linux-m68k.org> said:

    Andreas> On Mai 04 2020, Robert Pluim wrote:
    >> Also, I see this when coming out of sleep and connecting to the same
    >> wifi network, with the same IP, and the same DNS server, which I guess
    >> implicates Emacs more.

    Andreas> Perhaps you are just running into some conntrack timeout.

On macOS? That would be an achievement :-)

Although itʼs entirely possible the macOS stack has a similar feature.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 13:33                   ` Robert Pluim
@ 2020-05-04 14:35                     ` Andreas Schwab
  2020-05-04 14:46                       ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Andreas Schwab @ 2020-05-04 14:35 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

On Mai 04 2020, Robert Pluim wrote:

>>>>>> On Mon, 04 May 2020 15:13:38 +0200, Andreas Schwab <schwab@linux-m68k.org> said:
>
>     Andreas> On Mai 04 2020, Robert Pluim wrote:
>     >> Also, I see this when coming out of sleep and connecting to the same
>     >> wifi network, with the same IP, and the same DNS server, which I guess
>     >> implicates Emacs more.
>
>     Andreas> Perhaps you are just running into some conntrack timeout.
>
> On macOS? That would be an achievement :-)

conntrack is a network feature, nothing to do with any OS.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 14:35                     ` Andreas Schwab
@ 2020-05-04 14:46                       ` Robert Pluim
  2020-05-04 15:10                         ` Andreas Schwab
  0 siblings, 1 reply; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 14:46 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 16:35:06 +0200, Andreas Schwab <schwab@linux-m68k.org> said:

    Andreas> On Mai 04 2020, Robert Pluim wrote:
    >>>>>>> On Mon, 04 May 2020 15:13:38 +0200, Andreas Schwab <schwab@linux-m68k.org> said:
    >> 
    Andreas> On Mai 04 2020, Robert Pluim wrote:
    >> >> Also, I see this when coming out of sleep and connecting to the same
    >> >> wifi network, with the same IP, and the same DNS server, which I guess
    >> >> implicates Emacs more.
    >> 
    Andreas> Perhaps you are just running into some conntrack timeout.
    >> 
    >> On macOS? That would be an achievement :-)

    Andreas> conntrack is a network feature, nothing to do with any OS.

Then I donʼt understand the point youʼre trying to make.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 12:53               ` Robert Pluim
  2020-05-04 13:13                 ` Andreas Schwab
@ 2020-05-04 14:51                 ` Lars Ingebrigtsen
  2020-05-04 16:13                   ` Robert Pluim
  2020-05-04 15:38                 ` Eric Abrahamsen
  2 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-04 14:51 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> Also, I see this when coming out of sleep and connecting to the same
> wifi network, with the same IP, and the same DNS server, which I guess
> implicates Emacs more.

It's unlikely to be something on your machine that's the problem.  It's
unfortunately common for routers/firewalls to eject the apparently dead
connection from their routing tables, and when a new packet arrives
on that connection, it'll just discard it (instead of sending a RST
packet to you).  The result is a hanging connection.

In my experience, this is quite common for the NAT routers ISPs use in
front of your home, and less common for the firewalls that's close to
the server.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 14:46                       ` Robert Pluim
@ 2020-05-04 15:10                         ` Andreas Schwab
  2020-05-04 16:29                           ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Andreas Schwab @ 2020-05-04 15:10 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

On Mai 04 2020, Robert Pluim wrote:

>>>>>> On Mon, 04 May 2020 16:35:06 +0200, Andreas Schwab <schwab@linux-m68k.org> said:
>
>     Andreas> On Mai 04 2020, Robert Pluim wrote:
>     >>>>>>> On Mon, 04 May 2020 15:13:38 +0200, Andreas Schwab <schwab@linux-m68k.org> said:
>     >> 
>     Andreas> On Mai 04 2020, Robert Pluim wrote:
>     >> >> Also, I see this when coming out of sleep and connecting to the same
>     >> >> wifi network, with the same IP, and the same DNS server, which I guess
>     >> >> implicates Emacs more.
>     >> 
>     Andreas> Perhaps you are just running into some conntrack timeout.
>     >> 
>     >> On macOS? That would be an achievement :-)
>
>     Andreas> conntrack is a network feature, nothing to do with any OS.
>
> Then I donʼt understand the point youʼre trying to make.

When the timeout occurs, existing connections fail to work any more.
Since this is an inactivity timeout, it perfectly fits your usecase.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 12:53               ` Robert Pluim
  2020-05-04 13:13                 ` Andreas Schwab
  2020-05-04 14:51                 ` Lars Ingebrigtsen
@ 2020-05-04 15:38                 ` Eric Abrahamsen
  2020-05-04 16:28                   ` Robert Pluim
  2 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-04 15:38 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 30 Apr 2020 15:11:38 -0700, Eric Abrahamsen
> <eric@ericabrahamsen.net> said:
>
>     >> A DNS lookup failing should never make Gnus hang, so that's pretty
>     >> surprising.
>
>     Eric> This error comes in `nntp-open-connection', as the
>     Eric> condition-case error
>     Eric> caught from `open-network-stream'. I only just realized that's a lisp
>     Eric> function, but looking at it we should be using
>     Eric> `make-network-process'.
>
> Iʼd rather you didnʼt move in that direction. 'make-network-process'
> is low-level plumbing, 'open-network-stream' is what user code should
> be using. What feature is 'open-network-stream' missing for you?

Sorry, that was a very poorly-written sentence. What I meant was that
`open-network-stream' *does* use `make-network-process' internally, and
the hang is happening inside C code, not Lisp code. That was all I was
trying to say.

> Eric> The DNS lookup isn't hanging (or hanging Gnus) so much as it
>     Eric> is taking a
>     Eric> long time to fail, and then _continuing to fail until Emacs is
>     Eric> restarted_.
>
>     Eric> So I'm hoping this is unrelated to Gnus, and actually a problem with
>     Eric> Emacs caching the DNS server it's trying to use, which is later
>     Eric> unavailable on a new network. (But then why would I only see
>     Eric> this with
>     Eric> Gnus nntp connections? On the other hand, all my nnimap
>     Eric> connections are
>     Eric> localhost, nntp is my only non-local Gnus network connection.)
>
> Emacs doesnʼt directly address the DNS server, it uses getaddrinfo or
> getaddrinfo_a, which means any caching going on is in the IP
> stack. Although given that this is being seen on GNU/Linux and macOS,
> it may well be emacs at fault.
>
> Also, I see this when coming out of sleep and connecting to the same
> wifi network, with the same IP, and the same DNS server, which I guess
> implicates Emacs more.

I really don't know very much about networking, unfortunately. I'm just
trying to provide debugging data, possibly leads, baseless speculation,
and red herrings.

Eric


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 14:51                 ` Lars Ingebrigtsen
@ 2020-05-04 16:13                   ` Robert Pluim
  2020-05-04 16:36                     ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 16:13 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eric Abrahamsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 16:51:53 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> Also, I see this when coming out of sleep and connecting to the same
    >> wifi network, with the same IP, and the same DNS server, which I guess
    >> implicates Emacs more.

    Lars> It's unlikely to be something on your machine that's the problem.  It's
    Lars> unfortunately common for routers/firewalls to eject the apparently dead
    Lars> connection from their routing tables, and when a new packet arrives
    Lars> on that connection, it'll just discard it (instead of sending a RST
    Lars> packet to you).  The result is a hanging connection.

And no doubt they'll have some crappy justification for doing
it. <sigh>

    Lars> In my experience, this is quite common for the NAT routers ISPs use in
    Lars> front of your home, and less common for the firewalls that's close to
    Lars> the server.

Iʼve just sledgehammered in tcp-keepalives at 1 second intervals into
make-network-process, and that at least makes the detection of the
failed connection fast.

Eric, are you on GNU/Linux? I can cook up a patch for that platform to
try if you want.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 15:38                 ` Eric Abrahamsen
@ 2020-05-04 16:28                   ` Robert Pluim
  0 siblings, 0 replies; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 16:28 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 08:38:00 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:
    >> Iʼd rather you didnʼt move in that direction. 'make-network-process'
    >> is low-level plumbing, 'open-network-stream' is what user code should
    >> be using. What feature is 'open-network-stream' missing for you?

    Eric> Sorry, that was a very poorly-written sentence. What I meant was that
    Eric> `open-network-stream' *does* use `make-network-process' internally, and
    Eric> the hang is happening inside C code, not Lisp code. That was all I was
    Eric> trying to say.

OK, had me worried for a second there :-)

    >> Also, I see this when coming out of sleep and connecting to the same
    >> wifi network, with the same IP, and the same DNS server, which I guess
    >> implicates Emacs more.

    Eric> I really don't know very much about networking, unfortunately. I'm just
    Eric> trying to provide debugging data, possibly leads, baseless speculation,
    Eric> and red herrings.

Once upon a time, IP networking was relatively simple, but those days
are gone now. Red herrings I suspect Iʼd be partial to, Iʼve never
tried those :-)


Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 15:10                         ` Andreas Schwab
@ 2020-05-04 16:29                           ` Robert Pluim
  0 siblings, 0 replies; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 16:29 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Eric Abrahamsen, Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 17:10:32 +0200, Andreas Schwab <schwab@linux-m68k.org> said:

    Andreas> When the timeout occurs, existing connections fail to work any more.
    Andreas> Since this is an inactivity timeout, it perfectly fits your usecase.

I thought you were talking about in the local stack, now I see you
meant upstream devices. tcp keepalive time it is.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 16:13                   ` Robert Pluim
@ 2020-05-04 16:36                     ` Eric Abrahamsen
  2020-05-04 17:21                       ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-04 16:36 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 04 May 2020 16:51:53 +0200, Lars Ingebrigtsen
> <larsi@gnus.org> said:
>
>     Lars> Robert Pluim <rpluim@gmail.com> writes:
>     >> Also, I see this when coming out of sleep and connecting to the same
>     >> wifi network, with the same IP, and the same DNS server, which I guess
>     >> implicates Emacs more.
>
>     Lars> It's unlikely to be something on your machine that's the
>     Lars> problem. It's
>     Lars> unfortunately common for routers/firewalls to eject the
>     Lars> apparently dead
>     Lars> connection from their routing tables, and when a new packet arrives
>     Lars> on that connection, it'll just discard it (instead of sending a RST
>     Lars> packet to you).  The result is a hanging connection.
>
> And no doubt they'll have some crappy justification for doing
> it. <sigh>
>
>     Lars> In my experience, this is quite common for the NAT routers
>     Lars> ISPs use in
>     Lars> front of your home, and less common for the firewalls that's close to
>     Lars> the server.
>
> Iʼve just sledgehammered in tcp-keepalives at 1 second intervals into
> make-network-process, and that at least makes the detection of the
> failed connection fast.
>
> Eric, are you on GNU/Linux? I can cook up a patch for that platform to
> try if you want.

Yes, I'm on arch linux. I'd be happy to try this out. I'll be switching
networks later this morning, if you've got something on hand already!

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 04 May 2020 08:38:00 -0700, Eric Abrahamsen
> <eric@ericabrahamsen.net> said:
>     >> Iʼd rather you didnʼt move in that direction. 'make-network-process'
>     >> is low-level plumbing, 'open-network-stream' is what user code should
>     >> be using. What feature is 'open-network-stream' missing for you?
>
>     Eric> Sorry, that was a very poorly-written sentence. What I meant was that
>     Eric> `open-network-stream' *does* use `make-network-process'
>     Eric> internally, and
>     Eric> the hang is happening inside C code, not Lisp code. That was
>     Eric> all I was
>     Eric> trying to say.
>
> OK, had me worried for a second there :-)
>
>     >> Also, I see this when coming out of sleep and connecting to the same
>     >> wifi network, with the same IP, and the same DNS server, which I guess
>     >> implicates Emacs more.
>
>     Eric> I really don't know very much about networking,
>     Eric> unfortunately. I'm just
>     Eric> trying to provide debugging data, possibly leads, baseless
>     Eric> speculation,
>     Eric> and red herrings.
>
> Once upon a time, IP networking was relatively simple, but those days
> are gone now. Red herrings I suspect Iʼd be partial to, Iʼve never
> tried those :-)

When pickled, they're not bad.


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 16:36                     ` Eric Abrahamsen
@ 2020-05-04 17:21                       ` Robert Pluim
  2020-05-04 18:01                         ` Lars Ingebrigtsen
  2020-05-04 18:47                         ` Eric Abrahamsen
  0 siblings, 2 replies; 67+ messages in thread
From: Robert Pluim @ 2020-05-04 17:21 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 09:36:41 -0700, Eric Abrahamsen <eric@ericabrahamsen.net> said:

    >> Eric, are you on GNU/Linux? I can cook up a patch for that platform to
    >> try if you want.

    Eric> Yes, I'm on arch linux. I'd be happy to try this out. I'll be switching
    Eric> networks later this morning, if you've got something on hand already!

Be prepared for rather more network traffic when Gnus is idle.

diff --git a/src/process.c b/src/process.c
index 6e5bcf307a..fb0a20c797 100644
--- a/src/process.c
+++ b/src/process.c
@@ -38,6 +38,7 @@ Copyright (C) 1985-1988, 1993-1996, 1998-1999, 2001-2020 Free Software
 #include <sys/socket.h>
 #include <netdb.h>
 #include <netinet/in.h>
+#include <netinet/tcp.h>
 #include <arpa/inet.h>
 
 #endif	/* subprocesses */
@@ -3456,6 +3457,27 @@ connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos,
 	    optbits |= set_socket_option (s, key, val);
 	  }
       }
+      if (!p->is_server && p->socktype != SOCK_DGRAM)
+        {
+          int optval;
+          int sz = sizeof(optval);
+          /* Enable keepalive.  */
+          optval = 1;
+          if (setsockopt (s, SOL_SOCKET, SO_KEEPALIVE, &optval, sz))
+            report_file_error ("socket keepalive 1", Qnil);
+          /* Set idle time.  */
+          optval = 1;
+          if (setsockopt (s, IPPROTO_TCP, TCP_KEEPIDLE, &optval, sz))
+            report_file_error ("socket keepalive 2", Qnil);
+          /* Time between keepalives.  */
+          optval = 1;
+          if (setsockopt (s, IPPROTO_TCP, TCP_KEEPINTVL, &optval, sz))
+            report_file_error ("socket keepalive 3", Qnil);
+          /* Number of probes.  */
+          optval = 2;
+          if (setsockopt (s, IPPROTO_TCP, TCP_KEEPCNT, &optval, sz))
+            report_file_error ("socket keepalive 4", Qnil);
+        }
 
       if (p->is_server)
 	{



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 17:21                       ` Robert Pluim
@ 2020-05-04 18:01                         ` Lars Ingebrigtsen
  2020-05-05  7:41                           ` new wifi connection = nntp timeout = Emacs restart?, " Robert Pluim
  2020-05-04 18:47                         ` Eric Abrahamsen
  1 sibling, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-04 18:01 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> Be prepared for rather more network traffic when Gnus is idle.

I just had a thought -- there basically are no non-TLS connections in
use any more (that we care about).  So can the TLS layer help us with
this problem?

*gasp*

https://gnutls.org/manual/gnutls.html#index-gnutls_005fheartbeat_005fping

There's a TLS layer ping!

Could we somehow use that for something fun?  Like, for instance, have
nnimap (etc) send an asynchronous ping before a command, and if there is
no response to the ping, reconnect and retry?  That would be something
that could work on for all the different protocols, so we wouldn't have
to implement this all over the place.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 17:21                       ` Robert Pluim
  2020-05-04 18:01                         ` Lars Ingebrigtsen
@ 2020-05-04 18:47                         ` Eric Abrahamsen
  1 sibling, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-04 18:47 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Lars Ingebrigtsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Mon, 04 May 2020 09:36:41 -0700, Eric Abrahamsen
> <eric@ericabrahamsen.net> said:
>
>     >> Eric, are you on GNU/Linux? I can cook up a patch for that platform to
>     >> try if you want.
>
>     Eric> Yes, I'm on arch linux. I'd be happy to try this out. I'll
>     Eric> be switching
>     Eric> networks later this morning, if you've got something on hand already!
>
> Be prepared for rather more network traffic when Gnus is idle.

So I built with your diff, removed my dbus rule closing servers on
sleep, restarted Emacs, opened Gnus and connected to nntp, slept the
laptop, switched locations, opened up, and everything reconnected
perfectly on first refresh, I didn't even need the one-time "g" that the
dbus rule was there to solve.

Perhaps there's more network traffic going on, but I can ignore it.
Here's the output of:

ss -p -o state established | grep nntp

tcp   0      0 192.168.86.23:38724 159.69.161.202:nntp users:(("emacs",pid=127072,fd=20)) timer:(keepalive,,0)


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?, Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-04 18:01                         ` Lars Ingebrigtsen
@ 2020-05-05  7:41                           ` Robert Pluim
  2020-05-05  8:19                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Robert Pluim @ 2020-05-05  7:41 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eric Abrahamsen, Christian Barthel, ding

>>>>> On Mon, 04 May 2020 20:01:39 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> https://gnutls.org/manual/gnutls.html#index-gnutls_005fheartbeat_005fping

    Lars> There's a TLS layer ping!

Yes. It caused HeartBleed :-)

    Lars> Could we somehow use that for something fun?  Like, for instance, have
    Lars> nnimap (etc) send an asynchronous ping before a command, and if there is
    Lars> no response to the ping, reconnect and retry?  That would be something
    Lars> that could work on for all the different protocols, so we wouldn't have
    Lars> to implement this all over the place.

That could work. 1 ping with a 500ms timeout? Or do we need 2 for
those firewalls that will drop the first one?

Would adding something like

(unless (gnutls-ping (get-buffer-process (nnimap-buffer)))
        (delete-process (get-buffer-process (nnimap-buffer))))

to nnimap-send-command be enough?

    Eric> So I built with your diff, removed my dbus rule closing servers on
    Eric> sleep, restarted Emacs, opened Gnus and connected to nntp, slept the
    Eric> laptop, switched locations, opened up, and everything reconnected
    Eric> perfectly on first refresh, I didn't even need the one-time "g" that the
    Eric> dbus rule was there to solve.

So I think that indicates the direction we need to go in. Iʼm not sure
whether (ab)using tcp keepalive is better than Lars' idea, we'll have
to test both.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?, Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-05  7:41                           ` new wifi connection = nntp timeout = Emacs restart?, " Robert Pluim
@ 2020-05-05  8:19                             ` Lars Ingebrigtsen
  2020-05-05 11:55                               ` Robert Pluim
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-05  8:19 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> That could work. 1 ping with a 500ms timeout? Or do we need 2 for
> those firewalls that will drop the first one?
>
> Would adding something like
>
> (unless (gnutls-ping (get-buffer-process (nnimap-buffer)))
>         (delete-process (get-buffer-process (nnimap-buffer))))
>
> to nnimap-send-command be enough?

I was thinking more of an async interface.

gnutls-ping would return immediately, but return a status variable that
would evaluate to nil (as in "not gotten a pong"), that would change
(asynchronously) to t when the TLS layer got a response.

And then use that in the loop where we're waiting for a response on the
IMAP command.  That would mean that we introduce no extra latency for
the commands, but send then before we know whether the connection is
still up.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?, Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-05  8:19                             ` Lars Ingebrigtsen
@ 2020-05-05 11:55                               ` Robert Pluim
  2020-05-19 13:34                                 ` Lars Ingebrigtsen
  2020-05-19 13:36                                 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 67+ messages in thread
From: Robert Pluim @ 2020-05-05 11:55 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eric Abrahamsen, Christian Barthel, ding

>>>>> On Tue, 05 May 2020 10:19:22 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Robert Pluim <rpluim@gmail.com> writes:
    >> That could work. 1 ping with a 500ms timeout? Or do we need 2 for
    >> those firewalls that will drop the first one?
    >> 
    >> Would adding something like
    >> 
    >> (unless (gnutls-ping (get-buffer-process (nnimap-buffer)))
    >> (delete-process (get-buffer-process (nnimap-buffer))))
    >> 
    >> to nnimap-send-command be enough?

    Lars> I was thinking more of an async interface.

    Lars> gnutls-ping would return immediately, but return a status variable that
    Lars> would evaluate to nil (as in "not gotten a pong"), that would change
    Lars> (asynchronously) to t when the TLS layer got a response.

If we do that, then emacs has to implement the timeout logic for the
ping somewhere.

    Lars> And then use that in the loop where we're waiting for a response on the
    Lars> IMAP command.  That would mean that we introduce no extra latency for
    Lars> the commands, but send then before we know whether the connection is
    Lars> still up.

Hmm, OK. Unfortunately it looks like my GnuTLS is built without
heartbeat support, so I canʼt test it right now. I suspect thatʼs a
widespread configuration.

tcp keepalive has the advantage of being part of the IP stack.

Robert


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-02 19:07                                         ` Eric Abrahamsen
@ 2020-05-19 13:23                                           ` Lars Ingebrigtsen
  2020-05-21  0:45                                             ` Eric Abrahamsen
  0 siblings, 1 reply; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-19 13:23 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: David Engster, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've already had an off-list vote in the negative! But of course this
> would come protected behind a custom option. If we even think there's
> any point at all.
>
> If Lars had a magic bullet, I think he would have used it by now...

Yup.  :-/

The dbus stuff is good...  if you're using NetworkManager (or the like)
and have dbus and etc.  I'm not saying Gnus shouldn't come with code
like the suggested (quite the opposite; it would be very helpful for
many people -- could somebody write that as a patch?), but my
guesstimate is that this would fix the problem only for a subset of the
hangs...

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?, Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-05 11:55                               ` Robert Pluim
@ 2020-05-19 13:34                                 ` Lars Ingebrigtsen
  2020-05-19 13:36                                 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-19 13:34 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> Hmm, OK. Unfortunately it looks like my GnuTLS is built without
> heartbeat support, so I canʼt test it right now. I suspect thatʼs a
> widespread configuration.

Oh, darn.  Another unworkable "magic bullet" idea...

One of these days I'm going to implement some network timeout/reconnect
logic (the hard way) for sure.  As Emacs is my witness!

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?, Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-05 11:55                               ` Robert Pluim
  2020-05-19 13:34                                 ` Lars Ingebrigtsen
@ 2020-05-19 13:36                                 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-05-19 13:36 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eric Abrahamsen, Christian Barthel, ding

Robert Pluim <rpluim@gmail.com> writes:

> tcp keepalive has the advantage of being part of the IP stack.

Oh, forgot to respond to this bit -- I think TCP keepalive is a helpful
thing, but it doesn't respond quickly enough in some situations, so it's
not a full solution.

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-19 13:23                                           ` Lars Ingebrigtsen
@ 2020-05-21  0:45                                             ` Eric Abrahamsen
  2020-06-26  9:38                                               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 67+ messages in thread
From: Eric Abrahamsen @ 2020-05-21  0:45 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: David Engster, ding

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I've already had an off-list vote in the negative! But of course this
>> would come protected behind a custom option. If we even think there's
>> any point at all.
>>
>> If Lars had a magic bullet, I think he would have used it by now...
>
> Yup.  :-/
>
> The dbus stuff is good...  if you're using NetworkManager (or the like)
> and have dbus and etc.  I'm not saying Gnus shouldn't come with code
> like the suggested (quite the opposite; it would be very helpful for
> many people -- could somebody write that as a patch?), but my
> guesstimate is that this would fix the problem only for a subset of the
> hangs...

I can bang something together -- should this go in a separate
gnus-dbus.el library, or just in gnus.el or gnus-start.el, next to the
other "fundamental" stuff?

And do we want both the basic dbus thing and the NetworkManager code? Or
skip NetworkManager?

Looks like we'll hide this code behind something like:

(and (featurep 'dbusbind)
     gnus-dbus-shutdown-on-sleep)

Eric


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-21  0:45                                             ` Eric Abrahamsen
@ 2020-06-26  9:38                                               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 67+ messages in thread
From: Lars Ingebrigtsen @ 2020-06-26  9:38 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: David Engster, ding

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I can bang something together -- should this go in a separate
> gnus-dbus.el library, or just in gnus.el or gnus-start.el, next to the
> other "fundamental" stuff?

A separate gnus-dbus.el library would make sense, I think?

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


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: new wifi connection = nntp timeout = Emacs restart?
  2020-05-01 10:35                           ` David Engster
  2020-05-01 17:29                             ` Eric Abrahamsen
@ 2020-08-21 20:47                             ` Eric Abrahamsen
  1 sibling, 0 replies; 67+ messages in thread
From: Eric Abrahamsen @ 2020-08-21 20:47 UTC (permalink / raw)
  To: David Engster; +Cc: Lars Ingebrigtsen, ding


On 05/01/20 12:35 PM, David Engster wrote:
>> I have no idea if this is "The Best Way", probably not. Also, I'm not
>> seeing anything on resuming, but maybe there's another path for that...?
>> Or maybe I'm not letting my laptop sleep long enough?
>
> So at least for sleeping/waking this seems to be the easiest way:
>
> (require 'dbus)
>
> (defun 'my-go-to-sleep-handler (sleep-start)
>   ;; sleep-start will be 't' before sleeping and 'nil' on wakeup?
>   (when sleep-start
>      (gnus-close-all-servers)))
>
> (dbus-register-signal :system
> 		      "org.freedesktop.login1"
> 		      "/org/freedesktop/login1"
> 		      "org.freedesktop.login1.Manager"
> 		      "PrepareForSleep"
> 		      'my-go-to-sleep-handler)
>

Okay, I've finally done this up, as Bug#42977.


^ permalink raw reply	[flat|nested] 67+ messages in thread

end of thread, other threads:[~2020-08-21 20:48 UTC | newest]

Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-16 17:37 new wifi connection = nntp timeout = Emacs restart? Eric Abrahamsen
2020-04-17 11:46 ` Eric S Fraga
2020-04-17 12:20   ` Gijs Hillenius
2020-04-17 12:26     ` Andreas Schwab
2020-04-17 14:51       ` Eric Abrahamsen
2020-04-17 15:38         ` David Engster
2020-04-17 16:35           ` Eric Abrahamsen
2020-04-19  6:37 ` Christian Barthel
2020-04-19 17:32   ` Eric Abrahamsen
2020-04-19 18:02     ` Robert Pluim
2020-04-19 21:23       ` Eric Abrahamsen
2020-04-19 22:10       ` Eric Abrahamsen
2020-04-20  4:54         ` Eric Abrahamsen
2020-04-20  7:40         ` Andreas Schwab
2020-04-20 15:45           ` Eric Abrahamsen
2020-04-20 15:54             ` Robert Pluim
2020-04-20 18:24               ` Eric Abrahamsen
2020-04-21  8:36                 ` Alberto Luaces
2020-04-21 15:53                   ` Eric Abrahamsen
2020-04-22  7:37                     ` Alberto Luaces
2020-04-22  8:28                       ` Alberto Luaces
2020-04-30  5:26       ` Lars Ingebrigtsen
2020-04-30 17:34         ` Eric Abrahamsen
2020-04-30 21:49           ` Lars Ingebrigtsen
2020-04-30 22:11             ` Eric Abrahamsen
2020-05-04 12:53               ` Robert Pluim
2020-05-04 13:13                 ` Andreas Schwab
2020-05-04 13:33                   ` Robert Pluim
2020-05-04 14:35                     ` Andreas Schwab
2020-05-04 14:46                       ` Robert Pluim
2020-05-04 15:10                         ` Andreas Schwab
2020-05-04 16:29                           ` Robert Pluim
2020-05-04 14:51                 ` Lars Ingebrigtsen
2020-05-04 16:13                   ` Robert Pluim
2020-05-04 16:36                     ` Eric Abrahamsen
2020-05-04 17:21                       ` Robert Pluim
2020-05-04 18:01                         ` Lars Ingebrigtsen
2020-05-05  7:41                           ` new wifi connection = nntp timeout = Emacs restart?, " Robert Pluim
2020-05-05  8:19                             ` Lars Ingebrigtsen
2020-05-05 11:55                               ` Robert Pluim
2020-05-19 13:34                                 ` Lars Ingebrigtsen
2020-05-19 13:36                                 ` Lars Ingebrigtsen
2020-05-04 18:47                         ` Eric Abrahamsen
2020-05-04 15:38                 ` Eric Abrahamsen
2020-05-04 16:28                   ` Robert Pluim
2020-04-30 17:38         ` Eric Abrahamsen
2020-04-30 21:51           ` Lars Ingebrigtsen
2020-04-30 22:26             ` Eric Abrahamsen
2020-04-30 22:28               ` Lars Ingebrigtsen
2020-04-30 22:39                 ` Eric Abrahamsen
2020-04-30 22:55                   ` Lars Ingebrigtsen
2020-04-30 23:13                     ` Eric Abrahamsen
2020-04-30 23:23                       ` Lars Ingebrigtsen
2020-05-01  9:46                         ` David Engster
2020-05-01 10:35                           ` David Engster
2020-05-01 17:29                             ` Eric Abrahamsen
2020-05-01 20:51                               ` David Engster
2020-05-02  0:33                                 ` Eric Abrahamsen
2020-05-02 10:20                                   ` David Engster
2020-05-02 15:13                                     ` Eric Abrahamsen
2020-05-02 16:50                                       ` David Engster
2020-05-02 19:07                                         ` Eric Abrahamsen
2020-05-19 13:23                                           ` Lars Ingebrigtsen
2020-05-21  0:45                                             ` Eric Abrahamsen
2020-06-26  9:38                                               ` Lars Ingebrigtsen
2020-08-21 20:47                             ` Eric Abrahamsen
2020-05-01 18:06                         ` Eric Abrahamsen

Gnus development mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/ding

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 ding ding/ http://inbox.vuxu.org/ding \
		ding@inbox.vuxu.org
	public-inbox-index ding

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.emacs.gnus.general


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git