Hacker News new | past | comments | ask | show | jobs | submit login

shared connections with ControlMaster etc are really handy for things like scp or sshfs.

Using TRAMP for emacs to tab-complete remote filenames is really nice, and much faster if you have a control connection already established.

I've not come across the ControlPersist option before - it's something I'm going to have a poke with to see if it can replace my scripts that fire off a bunch of common host control connections in the background, and use autossh to resume them when I get a net connection or wake the laptop from sleep.




I use ControlPersist, but it doesn't seem to work well with mercurial. If hg makes the first ssh connection, hg won't exit until the master closes. ssh in a terminal then running hg doesn't have the same problem. The persistent connection child isn't detached enough apparently and hg waits for it. I'd be careful about testing auto connection sharing to make sure things don't get hung.


Yeah, the idea is that you ensure that the "master" channel; the first one, is always backgrounded (and connected), otherwise I intercept the ssh command and have it spawn a new master first.

The biggest downside to ControlMaster in general is when you accidentally close (well, kill) the master session, and everything else dies along with it. The usual behaviour is to close that channel on EOF, but wait until all other muxed connections are closed before actually exiting. If you forget it's the master and Ctrl-C it, bye bye sessions.

My backgrounding stuff is currently a horrible mess of Perl scripts, and a bit flakey when it comes to hostname/option parsing, but I might give it a tidy and stick it up on github at some point.


ControlMaster auto and ControlPersist are supposed to do the backgrounding automatically. I think it's just not "far enough" in the background.


You can turn it off when using Mercurial by putting something like this into your .hgrc file:

    [ui]
    ssh = ssh -o ControlMaster=no -o ControlPersist=no


The point, though, is that I want it on (and working) because it's fast. hg is responsible for the majority of my ssh connections.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: