ssh: Broken Pipe

dbbolton

dbbolton

I am trying to build xorg-minimal. I am doing this via ssh, despite other problems for the convenience of having a graphical web browser in the meantime.

Periodically, the ssh connection will spontaneously close after an extended period, with the incredibly vague message
Code: 
connection to (host) closed... broken pipe
This would lead me to believe that something went wrong with my router and the client could no longer talk to the server. So I sat down at the server, and oddly enough, I could ping both the router and arbitrary domains, such as "freebsd.org". If DNS is working, and the router is working, why is the pipe broken?

Edit: by the way, here is the relevant section of my ~/.ssh/config on the client:

Code: 
Host *
    Compression yes
    CompressionLevel 7
    Cipher  blowfish
    ServerAliveInterval 600
    ControlMaster auto
    ControlPath /tmp/ssh-%r@%h:%p
 
Most likely your router errorneously expires the state related to the connection for whatever reason. Ping and DNS use stateless traffic and they will work even if stateful tracking of TCP connections is broken.
 
What SSH client do you use? You may be able to enable keepalive packets in your SSH client to stop the connection state being disassociated. Maybe.
 
What SSH client do you use?
Click to expand...
OpenSSH, but it seems this option is enabled by default:

Code: 
      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.  This
              option only uses TCP keepalives (as opposed to using ssh level
              keepalives), so takes a long time to notice when the connection
              dies.  As such, you probably want the ServerAliveInterval option
              as well.  However, this means that connections will die if the
              route is down temporarily, and some people find it annoying.
 
              The default is “yes” (to send TCP keepalive messages), and the
              client will notice if the network goes down or the remote host
              dies.  This is important in scripts, and many users want it too.
 
I highly recommend sysutils/tmux. After you SSH into the machine run tmux(1) and start building. If the connection drops, log back in and [cmd=]tmux att[/cmd]. You'll notice the build continued as if nothing happened.

It saved my bacon numerous times when trying to administer a box half-way across the world on a buggy connection.
 
Running something like screen or tmux is an even better idea. That way you're free to disconnect, power down your laptop (if that's what you're SSH'd in from), etc.
 
dbbolton said:
I tried this, and just got the message "no sessions".
Click to expand...
Well, work has been rough for me as of late but I'm working on a nice HOWTO and with a little luck will have it finished around upcoming weekend.

What @wblock@ described up there was the procedure to attach tmux to an already existing session. But if you don't have a session just yet you'll need to start one. You can do that by simply starting tmux without any extra parameters.

But before you do that I suggest you create a file ~/.tmux.conf (so .tmux.conf in your home directory) and add these lines:

Code: 
# Screen-like behaviour
set-option -g prefix C-a
unbind-key C-b
bind-key a send-prefix

After you did that you can use Control-a to control tmux and because both the control and a key sit right next to each other you can do this with one hand. By default tmux uses Control-b which is a little more difficult to use.

Now, I do advice reading the tmux(1) manual page as well as skimming through the documentation in /usr/local/share/doc/tmux, but even so..

After starting tmux you can use Control-a c (control-a followed by c) to create a new virtual console. You can simply exit a console to close it. When you wish to logout from your system but keep your programs running you can use Control-a d (control-a followed by d) which will detach the current session, effectively keeping your software running in the background.

In this particular situation can you use the command which @wblock@ mentioned up there. tmux list will list the available sessions and tmux attach (or the short form) will now (re)attach you to the previously detached session.

Just a quick "tmux 101".
 
Last edited by a moderator:
Thanks for the advice. I actually have a configuration file: https://github.com/dbb/githome/blob/master/.tmux.conf. I do have ^a as my prefix.

Why would I need to unbind Ctrl+b if Ctrl+a is bound? And what exactly is send-prefix for? The manual's explanation isn't very helpful: "Send the prefix key, or with -2 the secondary prefix key, to a window as if it was pressed."

But if you don't have a session just yet you'll need to start one. You can do that by simply starting tmux without any extra parameters.
Click to expand...

I connected to the FreeBSD machine via ssh, ran tmux, the pipe broke, I reconnected, and then I ran tmux again and got that error. Is that not correct? Do I need to run tmux &, or perhaps run it from the host machine?
 
With no options, tmux starts a session. To reconnect to that session, use tmux attach.

The "prefix key" is the key used to get tmux's attention. That gives a way to send that key through to an application.

Personally, I would not change the default key, because then it will have to be changed on each new machine.
 
You must log in or register to reply here.
Back
Top