* 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 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 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 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 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 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 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: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 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?, 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?, 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-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? 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 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-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: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: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-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-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? 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
* 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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).