From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: Preventing ERC automated channel disconnects Date: Sat, 5 Dec 2015 13:41:49 -0700 Message-ID: <20151205124313155407128@bob.proulx.com> References: <20151203140749137430306@bob.proulx.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1449348134 23599 80.91.229.3 (5 Dec 2015 20:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Dec 2015 20:42:14 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Dec 05 21:42:10 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a5Jeh-0000NF-Sx for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Dec 2015 21:42:08 +0100 Original-Received: from localhost ([::1]:47697 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5Jeh-0003BY-5S for geh-help-gnu-emacs@m.gmane.org; Sat, 05 Dec 2015 15:42:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5JeW-0003BS-03 for help-gnu-emacs@gnu.org; Sat, 05 Dec 2015 15:41:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5JeR-00066L-V1 for help-gnu-emacs@gnu.org; Sat, 05 Dec 2015 15:41:55 -0500 Original-Received: from havoc.proulx.com ([96.88.95.61]:33909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5JeR-000667-OG for help-gnu-emacs@gnu.org; Sat, 05 Dec 2015 15:41:51 -0500 Original-Received: from joseki.proulx.com (localhost [127.0.0.1]) by havoc.proulx.com (Postfix) with ESMTP id 132A3E42 for ; Sat, 5 Dec 2015 13:41:50 -0700 (MST) Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id A97722183B for ; Sat, 5 Dec 2015 13:41:49 -0700 (MST) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 694842DC5B; Sat, 5 Dec 2015 13:41:49 -0700 (MST) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 96.88.95.61 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:108306 Archived-At: Alan Schmitt wrote: > Bob Proulx writes: > > I use an irc bouncer proxy to maintain a persistent connection. > > I did not know about IRC bouncers, so I looked it up, and I really like > the idea It works pretty well. It means that on my laptop when I am connected that I have a local client for my typing instead of the many terrible high latency WAN connections that I happen to be on at various client sites. It means I get a local notification (beep, balloon) when I am messaged. The local client connects when it can and retries when it can't. Without a bouncer it would mean that my account presence would be coming and going and coming and going all of the time which is somewhat annoying to others unless I only used a persistent server. Also when offline I would be unavailable for messaging. With the alternative of a persistent remote server I would be suffering from the terrible network connections I too often work in. The local notifications are the main advantage I like of using the irc bouncer. It allows me to be coordinating with other team members more effectively when working a problem without needing to be checking (polling) my remote irc client during the work. Meanwhile this doesn't remove the advantage of having a persistent server keeping the session alive. The advantage there is that my team members can always message me even when I am offline. When I come online I will check my messages and see anything that was sent to me and be able to respond. In many ways it makes this more like email. Generally I prefer email. But others prefer other things and this is a compromise that sits between. And also when the conversation starts up again it is just normal irc again. > (I'm currently using weechat in a tmux session on a server to stay > connected, I am doing almost the same thing using 'screen' and 'irssi'. I go back and forth on using 'mosh' (the mobile shell) or not. It has some quirks that one needs to know about, specifically it will leave orphan processes behind unless you avoid doing so. But I am back to using it again and it has advantages if you drive it. https://mosh.mit.edu/ If you haven't tried 'mosh' then in your situation I suggest giving it a try. It is very clever. It uses normal ssh to start a UDP connection for the communication between. It is specifically designed for use in high latency, high packet loss, and unreliable networks. That part it does very well. That is the main reason I use it and like it. But mosh has a basic flaw that it doesn't specifically address. The mosh server side creates a persistent presence somewhat like screen and tmux do. Which is how it allows you to reconnect seamlessly. But if the client side dies while offline nothing ever cleans up that remote shell. And since the client has died nothing will ever be able to connect to that server side of the session again either. The server side of the session will be left as an orphan. Anything running in that session will hang around and consume memory and resources until it is manually killed. Periodically it is a good idea to run a ps listing and look for orphan processes and clean them up manually. But here is the trick to avoid it. Never run a simple shell on the remote side of a mosh connection. A simple shell could be left hanging with no way to reconnect to it. Instead start up a screen or tmux session and only use mosh to resume a running screen or tmux. That way when a new login comes along and resumes the screen / tmux it will cause the mosh server to see that the process is finished and the mosh server will exit too. If you only run mosh resuming screen sessions then it won't ever leave orphaned processes behind. mosh -- myserver.example.com screen -dR The '--' is needed because 'mosh' also inconveniently looks for its own options anywhere on the command line. For a command that runs other commands that is an unfortunate choice. Using '--' tells mosh that it has no more options to the right and the -dR is then passed through as part of the 'screen -dR' command on the remote system. For screen the -d option detaches the remote session first so that it can be re-attached. Then the -R resumes the unattached session. Same as -r but -R starts a session if one is not running. Resume or start. I know you said you were using tmux. I am sure it is similar things there too. But I only know screen and therefore I only talked about screen. > but it's outside of emacs which is sad). Which is exactly why I would like to be able to use emacs too. But at the moment using erc means that it disconnects everything every time I use it. Bad. (Unless I take extreme measures to cut the network before it can disconnect, then exit erc while it can't tell the remote end to leave channels.) Otherwise I would be using emacs erc as my irc client. > Which irc bouncer would you recommend using? I don't have any specific recommendation. I happen to be using irssi because through my route through irc clients it was the one I liked and was using and irssi also provides an irc bouncer proxy. Therefore I happen to be using it. And the bouncer feature works well enough. But if someone were wanting *only* an irc bouncer I don't think irssi is particularly outstanding if that is the only task it is doing. A good friend of mine is using 'Bip'. It sounds interesting. I have been wanting to set it up and try it. I think if you were going to start somewhere that Bip might be a good place to start. But note that I haven't tried it yet myself. Bob