19

When I try to rsync -qaPH source/ 192.168.1.21:/var/backups I get 

rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(837) [sender=3.1.0]

Whats wrong with my command?

Alex
  • 429
  • 1
  • 4
  • 11
  • I guess the error is occurring on this line: https://git.samba.org/rsync.git/?p=rsync.git;a=blob;f=io.c;h=303690#l837 . If you can wade through the surrounding code, it might tell you roughly what happened. – mwfearnley Jul 14 '16 at 10:15

7 Answers7

10

To investigate, add one or more -v options to the rsync command. Also, try to use plain ssh:

ssh -v 192.168.1.21 /bin/true

to find out whether it is rsync or the underlying ssh connection that is causing the trouble.

Arjen
  • 366
  • 3
  • 5
  • 1
    For me it was a problem in my ssh-config, I used `RemoteCommand /bin/sh -c 'tmux has-session && exec tmux attach || exec tmux'` for one server – Alfred Bez May 25 '20 at 11:22
7

255 is actually not a "native" rsync return code. rsync scrapes the 255 error code from SSH and returns it. It looks to me like something on the destination server is blocking SSH or breaking it once it's connected, hence, "broken pipe". I disagree with @kenorb because if it were a timeout issue you would probably be seeing rsync exit codes 30 or 35.

medley56
  • 215
  • 2
  • 10
4

Broken pipe error most likely means that you've hit the timeout. For example the remote rsync command started to calculate the file differences, but it didn't replied to the client on time.

If this happens very often, add these settings to your local ~/.ssh/config:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 6

and on the remote server (if you've got the access), setup these in your /etc/ssh/sshd_config:

ClientAliveInterval 30
ClientAliveCountMax 6

See: What the options ServerAliveInterval and ClientAliveInterval mean?

Community
  • 1
kenorb
  • 9,995
  • 2
  • 78
  • 90
1

I got the 255 error when rsnapshot using rsync encountered the situation "The ECDSA host key for foobar has changed". The rest of the error message included "POSSIBLE DNS SPOOFING DETECTED" and "REMOTE HOST IDENTIFICATION HAS CHANGED".

I had recreated my server and so the fingerprint had changed. I removed the ECDSA key (ssh-keygen -f "/home/bruce/.ssh/known_hosts" -R "foobar") and agreed to the new one when I sshed into foobar again.

ssh -vvv foobar gave me the info I needed to see this issue.

Pilot6
  • 88,764
  • 91
  • 205
  • 313
Bruce
  • 11
  • 1
0

Anyone who comes across this error suddenly, it possibly could be because of your UFW (firewall).

I used a setup that adds ufw limit ssh and that limits only 6 connections within a 30 second time (standard).

I noticed this because our deploy scripts were constantly hitting the server with a series of commands + with rsync's and reaching the limit.

To avoid the SSH limit, insert a rule BEFORE the ssh limit with your server IP. This will stop it refusing the connection and allowed it to connect as normal. You can do this with:

ufw insert 1 allow from 10.10.10.10 to any port 22 proto tcp

Obviously change 10.10.10.10 for your server IP.

This will insert the rule before the rate limit and wont refuse the connection anymore.

Repeat the same rules for as many IPs you need.

ufw status will show the rules in order of priority, so hopefully now your server rule is before the ssh limit and will connect as normal with no issues.

jsonUK
  • 101
  • 2
0

I know this issue is old, but maybe someone (like me) still have the error.

a) Check if the ssh service is running:

sudo service ssh status

b) Check the connection with triple verbose command:

ssh -vvv <hostname>

c) Maybe you use the wrong ssh-key or the key is broken in some way.

Vine

vine
  • 11
0

I had a similar error using rsync via my deploy for an Ember app (ember-cli-deploy). I had to configure correctly my ssh (add private keys to my ~/.ssh/)

morhook
  • 1,583
  • 13
  • 22