7 ms·

You'd be far better off learning screen or tmux than by using shared connections. Knowledge of that will improve your offline options as well, will transfer to

You'd be far better off learning screen or tmux than by using shared connections. Knowledge of that will improve your offline options as well, will transfer to any ssh client (including Putty), and IMO is far more useful than having two separate terminal/ssh windows.

losvedir 15y ago
Agreed. I actually did a Cmd+F "tmux" and "screen" after skimming the article to make sure I didn't miss it somehow. A terminal multiplexer is an absolute must if your connection is likely to be interrupted. Closing the laptop, moving to a different room and picking up right where you left off is great.
- jff 15y ago
  If ssh servers and clients didn't use their own "keepalive" messages, you'd be able to do that anyway. TCP is supposed to be able to pick up right where it left off, so your ssh connections shouldn't die if you lose connection for a few minutes.
  - shabble 15y ago
    man ssh_config: TCPKeepAlive Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying.
    - pyre 15y ago
      Turning off TCPKeepAlive also could mean that stale connections are killed. We have a router that kills connections that have been stale > 2 hours. I run my screen session on a single server and ssh to all other servers within that screen session. Without TCPKeepAlive, I would lose most of my session overnight (or after a string of meetings).
  - dedward 15y ago
    If you lose some packets for a few minutes, it shouldn't die,but there are a zillion real world situations where it can and WILL die....... and it's not an SSH problem, screen was useful for the same reason long before ssh.
cabacon 15y ago
I don't know - I like having the control master around for when I've done something like startup an interactive process, then realize that I also want to pop onto the machine to look in some file. I don't always start screen when I login somewhere, and I don't particularly like screen well enough to make it my default first action when I log in somewhere. I also tend to prefer to be able to see all my logins simultaneously, rather than having them be screen windowed or tabbed. I thought it was a nice overview of some things I use a lot (control master, and nicknames in .config) and included some things I didn't know, like the control persistence and some of the nickname wildcarding. It shouldn't be dismissed just because it isn't about screen/tmux.
- nuclear_eclipse 15y ago
  If it's a long-running process, you might want to consider screen if only for the protection against connection issues. Otherwise, you could potentially combine the control master with `screen -x`, or just use a split window in screen/tmux, to allow viewing multiple windows at once.
senko 15y ago
I tend to edit files locally and rsync (the changes) to the server, running rsync over ssh. I do this fairly often (edit - save - rsync - check), and avoiding time to set up a new ssh connection is a huge speed boost to my use case (since the delta is usually quite small). Even if I don't need to be logged in to the server at all, I still do it so it keeps the master connection open, and then speed up the rsyncs.
- dwc 15y ago
  Have you considered doing something like pushing with git?
  - tedunangst 15y ago
    Every push with git is going to create a new ssh connection. Using a shared connection is way faster.
  - senko 15y ago
    This would suffer from the same problem. But doing git push all is out of the question for me, because I'm rsyncing while developing, so I'd need to constantly commit and push tiny nonsensical commits to the server, and then do a massive rebase afterwards. In effect, it's more work and gains me nothing.
    - wfarr 15y ago
      I hope this is some sort of staging or testing server? The idea of repeatedly writing code and rsyncing it up to a production server while adding new features/whatever seems incredibly error prone to me. And that's not even to touch on whether or not there's automated testing (in the form of unit/integration/whatever tests in the code).
      - senko 15y ago
        Yeah, it's a development server. I've got a cheap VPS (€4/mo with 512MB of memory) and I usually run the code I'm developing there. My reasons: I don't have to pollute my laptop with various (sometimes mutually exclusive) servers - virtualenv &co are great, but can only go so far, and VMs are much harder on the battery; trivial for other people (colleagues, clients) to see WIP, even if my laptop is suspended.
shabble 15y ago
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.
- tedunangst 15y ago
  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.
  - shabble 15y ago
    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.
    - tedunangst 15y ago
      ControlMaster auto and ControlPersist are supposed to do the backgrounding automatically. I think it's just not "far enough" in the background.
  - 15y ago
barrkel 15y ago
My problem with nested terminal emulators is that they reimplement the scroll buffer (by necessity). This in turn breaks the native buffer scrolling keyboard shortcuts of the outermost terminal. For some servers, this is worth the pain; for others, it's not.
- guns 15y ago
  So use a better terminal emulator. Rxvt-unicode allows you to pass mouse drags and scrolls directly to the terminal by holding down shift, and since it supports perl extensions, there are many ways to scroll back and yank from the terminal's buffer. Tmux is great even if you're not using it as a process manager; it dramatically increased my productivity at the terminal (which is most of my day)
  - TREYisRAD 15y ago
    Emulating as rxvt doesn't seem to have the desired effect on iTerm2 on OSX. Is there another solution? Entering copy-mode on tmux/screen isn't ideal.
  - guns 15y ago
    @TREYisRAD No, you'll want to actually use rxvt-unicode [1] on X11 on your Mac. The X implementation is annoying at times on OS X, but using a great terminal is worth it if you spend all your time in one. iTerm2 is nice, and Lion's new Terminal.app isn't bad, but programs like vim and tmux are designed with real xterm-compatible terminals in mind [2]. [1]: http://dist.schmorp.de/rxvt-unicode/ http://dist.schmorp.de/rxvt-unicode/ [2]: For instance, you can enter copy-mode in tmux 1.5 with a mouse scroll if you are using xterm or rxvt-unicode
    - lmz 15y ago
      The developers of iTerm2 and tmux are working on better integration: http://code.google.com/p/iterm2/wiki/TmuxIntegration http://code.google.com/p/iterm2/wiki/TmuxIntegration
  - barrkel 15y ago
fdb 15y ago
Any good resources for learning screen? So far I've only mastered: "Ctrl-a d" and "screen -r" I'd love to hear how you use screen, for example. Do you use multiple sessions or windows? Split screen?
- ordinary 15y ago
  You're missing out. After (or maybe alongside) those two keys, I find the most useful ones are: Ctrl-a c (to create a new terminal) Ctrl-a 1 (to go to the first terminal) Ctrl-a 2 (second, etc) If you're an emacs user, you might also want to change the command key away from something as essential as the default bind for beginning-of-line. I myself use Ctrl-T. In .screenrc, that would be: escape ^Tt The screen manpage is also very good.
  - dredmorbius 15y ago
    Add to that list C-a " to view the list of screens. C-a A can be used to assign names to those screens. C-a [0-9] can be used to navigate directly to a specific screen. C-a C-a will swap the current and previous screen. C-a S splits the screen vertically C-a <tab> navigates to the next visible screen (there's no back-navigation). C-a q collapses all splits leaving the current screen visible. C-a d detaches from the screen session. There are some other features, but with these you're using much of the power of screen. Takes a few days to get used to, but it's one of those "how did I ever live without this" tools.
- nuclear_eclipse 15y ago
  I personally use screen in a relatively "simple" way. I don't use splits, but I do occasionally use `screen -x` to have multiple views of the same screen session. My biggest use of screen is for running a persistent Irssi session on my server, and connecting to that from whatever terminal or mobile device I happen to be sitting in front of. In that case, I have just a couple active windows, but only one that I use 95% of the time. I have a similar persistent screen session on my work machine for running Irssi's SILC client to chat with co-workers. I also use screen for my primary workflow, because a lot of my development takes place on servers. I'll start a screen session on each server, and create a new window for each type of task I'm performing. Eg, I have a window each for `htop`, mongodb console, vim, git, and for running the program I'm working on, plus a few others for one-off tasks like installing a new package or editing a system configuration file. Some tips I have include: - Set up a nice .screenrc file, and make yourself a customized "caption" line, which will give you a status bar of sorts that will list all your open windows. Mine is `caption always "%{= dd}%{+b ky}%{+ .b} $LOGNAME@%H %{-} %{.y}%-w%50>%{+ Kg} %n %t %{-}%+w%<%{-}"` - Similary, either get in the habit of naming your windows, or set up your shell to properly report commands to screen so it can automatically name them based on the command you've run. My zshell config does this for both screen and gnome-terminal: https://github.com/jreese/oh-my-zsh/blob/jreese/custom/screen-titles.zsh https://github.com/jreese/oh-my-zsh/blob/jreese/custom/scree... - Ctrl-a, Ctrl-a is a great combination for "alt-tabbing" between windows - I set my least-used window to #0, as it's the "hardest" number to hit after ctrl-a, and I put my most used windows between #1 and #5 for easy one-handed switching. - Ctrl-a Escape is the easiest way to get into copy mode to view your scrollback buffer. Ctrl-a [ is equivalent, but IMO using escape instead allows me to start moving my right hand to the cursor/paging keys while I'm still using my left hand to enter copy mode.
spudlyo 15y ago
Connection sharing and terminal multiplexers aren't mutually exclusive. Let's say that in order to get to 4-5 hosts (which you run screen on) you have to jump through a certain SSH bastion host which you specify using the ProxyCommand directive. You're going to want connection sharing on that bastion host, to make subsequent connections to hosts beyond much faster. If you have to jump through two bastion hosts to get where you have to go (yes I actually have to do this) connection sharing is a must. Even without a bastion host, connection sharing allows for faster scp from your home box to the target host you're running screen on.
zobzu 15y ago
No, screen/tmux does not solve the same issues shared connection do. In fact, they've little to do which each other. Screens allow you to keep your session running and reattach to it. Control (shared connection) allow you to keep the connection running instead of opening multiple ones. This is much much faster for example if you're using SCP, or have scripts opening different tunnels, and so on.
- sukuriant 15y ago
  I think the point is the "normal use case for screen", which tends to be, for me: keep alive, and sometimes multiple sessions in one window.

losvedir 15y ago

Agreed. I actually did a Cmd+F "tmux" and "screen" after skimming the article to make sure I didn't miss it somehow. A terminal multiplexer is an absolute must if your connection is likely to be interrupted. Closing the laptop, moving to a different room and picking up right where you left off is great.

jff 15y ago
If ssh servers and clients didn't use their own "keepalive" messages, you'd be able to do that anyway. TCP is supposed to be able to pick up right where it left off, so your ssh connections shouldn't die if you lose connection for a few minutes.
- shabble 15y ago
  man ssh_config: TCPKeepAlive Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying.
  - pyre 15y ago
    Turning off TCPKeepAlive also could mean that stale connections are killed. We have a router that kills connections that have been stale > 2 hours. I run my screen session on a single server and ssh to all other servers within that screen session. Without TCPKeepAlive, I would lose most of my session overnight (or after a string of meetings).
- dedward 15y ago
  If you lose some packets for a few minutes, it shouldn't die,but there are a zillion real world situations where it can and WILL die....... and it's not an SSH problem, screen was useful for the same reason long before ssh.

cabacon 15y ago

I don't know - I like having the control master around for when I've done something like startup an interactive process, then realize that I also want to pop onto the machine to look in some file. I don't always start screen when I login somewhere, and I don't particularly like screen well enough to make it my default first action when I log in somewhere. I also tend to prefer to be able to see all my logins simultaneously, rather than having them be screen windowed or tabbed. I thought it was a nice overview of some things I use a lot (control master, and nicknames in .config) and included some things I didn't know, like the control persistence and some of the nickname wildcarding. It shouldn't be dismissed just because it isn't about screen/tmux.

nuclear_eclipse 15y ago
If it's a long-running process, you might want to consider screen if only for the protection against connection issues. Otherwise, you could potentially combine the control master with `screen -x`, or just use a split window in screen/tmux, to allow viewing multiple windows at once.

senko 15y ago

I tend to edit files locally and rsync (the changes) to the server, running rsync over ssh. I do this fairly often (edit - save - rsync - check), and avoiding time to set up a new ssh connection is a huge speed boost to my use case (since the delta is usually quite small). Even if I don't need to be logged in to the server at all, I still do it so it keeps the master connection open, and then speed up the rsyncs.

dwc 15y ago
Have you considered doing something like pushing with git?
- tedunangst 15y ago
  Every push with git is going to create a new ssh connection. Using a shared connection is way faster.
- senko 15y ago
  This would suffer from the same problem. But doing git push all is out of the question for me, because I'm rsyncing while developing, so I'd need to constantly commit and push tiny nonsensical commits to the server, and then do a massive rebase afterwards. In effect, it's more work and gains me nothing.
  - wfarr 15y ago
    I hope this is some sort of staging or testing server? The idea of repeatedly writing code and rsyncing it up to a production server while adding new features/whatever seems incredibly error prone to me. And that's not even to touch on whether or not there's automated testing (in the form of unit/integration/whatever tests in the code).
    - senko 15y ago
      Yeah, it's a development server. I've got a cheap VPS (€4/mo with 512MB of memory) and I usually run the code I'm developing there. My reasons: I don't have to pollute my laptop with various (sometimes mutually exclusive) servers - virtualenv &co are great, but can only go so far, and VMs are much harder on the battery; trivial for other people (colleagues, clients) to see WIP, even if my laptop is suspended.

shabble 15y ago

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.

tedunangst 15y ago
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.
- shabble 15y ago
  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.
  - tedunangst 15y ago
    ControlMaster auto and ControlPersist are supposed to do the backgrounding automatically. I think it's just not "far enough" in the background.
- 15y ago

barrkel 15y ago

My problem with nested terminal emulators is that they reimplement the scroll buffer (by necessity). This in turn breaks the native buffer scrolling keyboard shortcuts of the outermost terminal. For some servers, this is worth the pain; for others, it's not.

guns 15y ago
So use a better terminal emulator. Rxvt-unicode allows you to pass mouse drags and scrolls directly to the terminal by holding down shift, and since it supports perl extensions, there are many ways to scroll back and yank from the terminal's buffer. Tmux is great even if you're not using it as a process manager; it dramatically increased my productivity at the terminal (which is most of my day)
- TREYisRAD 15y ago
  Emulating as rxvt doesn't seem to have the desired effect on iTerm2 on OSX. Is there another solution? Entering copy-mode on tmux/screen isn't ideal.
- guns 15y ago
  @TREYisRAD No, you'll want to actually use rxvt-unicode [1] on X11 on your Mac. The X implementation is annoying at times on OS X, but using a great terminal is worth it if you spend all your time in one. iTerm2 is nice, and Lion's new Terminal.app isn't bad, but programs like vim and tmux are designed with real xterm-compatible terminals in mind [2]. [1]: http://dist.schmorp.de/rxvt-unicode/ http://dist.schmorp.de/rxvt-unicode/ [2]: For instance, you can enter copy-mode in tmux 1.5 with a mouse scroll if you are using xterm or rxvt-unicode
  - lmz 15y ago
    The developers of iTerm2 and tmux are working on better integration: http://code.google.com/p/iterm2/wiki/TmuxIntegration http://code.google.com/p/iterm2/wiki/TmuxIntegration
- barrkel 15y ago

fdb 15y ago

Any good resources for learning screen? So far I've only mastered: "Ctrl-a d" and "screen -r" I'd love to hear how you use screen, for example. Do you use multiple sessions or windows? Split screen?

ordinary 15y ago
You're missing out. After (or maybe alongside) those two keys, I find the most useful ones are: Ctrl-a c (to create a new terminal) Ctrl-a 1 (to go to the first terminal) Ctrl-a 2 (second, etc) If you're an emacs user, you might also want to change the command key away from something as essential as the default bind for beginning-of-line. I myself use Ctrl-T. In .screenrc, that would be: escape ^Tt The screen manpage is also very good.
- dredmorbius 15y ago
  Add to that list C-a " to view the list of screens. C-a A can be used to assign names to those screens. C-a [0-9] can be used to navigate directly to a specific screen. C-a C-a will swap the current and previous screen. C-a S splits the screen vertically C-a <tab> navigates to the next visible screen (there's no back-navigation). C-a q collapses all splits leaving the current screen visible. C-a d detaches from the screen session. There are some other features, but with these you're using much of the power of screen. Takes a few days to get used to, but it's one of those "how did I ever live without this" tools.
nuclear_eclipse 15y ago
I personally use screen in a relatively "simple" way. I don't use splits, but I do occasionally use `screen -x` to have multiple views of the same screen session. My biggest use of screen is for running a persistent Irssi session on my server, and connecting to that from whatever terminal or mobile device I happen to be sitting in front of. In that case, I have just a couple active windows, but only one that I use 95% of the time. I have a similar persistent screen session on my work machine for running Irssi's SILC client to chat with co-workers. I also use screen for my primary workflow, because a lot of my development takes place on servers. I'll start a screen session on each server, and create a new window for each type of task I'm performing. Eg, I have a window each for `htop`, mongodb console, vim, git, and for running the program I'm working on, plus a few others for one-off tasks like installing a new package or editing a system configuration file. Some tips I have include: - Set up a nice .screenrc file, and make yourself a customized "caption" line, which will give you a status bar of sorts that will list all your open windows. Mine is `caption always "%{= dd}%{+b ky}%{+ .b} $LOGNAME@%H %{-} %{.y}%-w%50>%{+ Kg} %n %t %{-}%+w%<%{-}"` - Similary, either get in the habit of naming your windows, or set up your shell to properly report commands to screen so it can automatically name them based on the command you've run. My zshell config does this for both screen and gnome-terminal: https://github.com/jreese/oh-my-zsh/blob/jreese/custom/screen-titles.zsh https://github.com/jreese/oh-my-zsh/blob/jreese/custom/scree... - Ctrl-a, Ctrl-a is a great combination for "alt-tabbing" between windows - I set my least-used window to #0, as it's the "hardest" number to hit after ctrl-a, and I put my most used windows between #1 and #5 for easy one-handed switching. - Ctrl-a Escape is the easiest way to get into copy mode to view your scrollback buffer. Ctrl-a [ is equivalent, but IMO using escape instead allows me to start moving my right hand to the cursor/paging keys while I'm still using my left hand to enter copy mode.

spudlyo 15y ago

Connection sharing and terminal multiplexers aren't mutually exclusive. Let's say that in order to get to 4-5 hosts (which you run screen on) you have to jump through a certain SSH bastion host which you specify using the ProxyCommand directive. You're going to want connection sharing on that bastion host, to make subsequent connections to hosts beyond much faster. If you have to jump through two bastion hosts to get where you have to go (yes I actually have to do this) connection sharing is a must. Even without a bastion host, connection sharing allows for faster scp from your home box to the target host you're running screen on.

zobzu 15y ago

No, screen/tmux does not solve the same issues shared connection do. In fact, they've little to do which each other. Screens allow you to keep your session running and reattach to it. Control (shared connection) allow you to keep the connection running instead of opening multiple ones. This is much much faster for example if you're using SCP, or have scripts opening different tunnels, and so on.

sukuriant 15y ago
I think the point is the "normal use case for screen", which tends to be, for me: keep alive, and sometimes multiple sessions in one window.