Rsync tworzy niewyjaśniony komunikat o błędzie (kod 255) w io.c (837)

Kiedy próbuję rsync -qaPH source/ 192.168.1.21:/var/backupsdostać

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

Co jest nie tak z moim poleceniem?

Aby to sprawdzić, dodaj jedną lub więcej -vopcji do polecenia rsync. Spróbuj także użyć zwykłego ssh:

ssh -v 192.168.1.21 /bin/true

aby dowiedzieć się, czy przyczyną problemów jest rsync czy leżące u podstaw połączenie ssh.

255 nie jest tak naprawdę „natywnym” rsynckodem powrotu. rsynczgarnia kod błędu 255 z SSH i zwraca go. Wygląda mi na to, że coś na serwerze docelowym blokuje SSH lub psuje je po podłączeniu, stąd „zepsuta rura”. Nie zgadzam się z @kenorb, ponieważ gdyby wystąpił problem z przekroczeniem limitu czasu, prawdopodobnie zobaczysz rsynckody wyjścia 30 lub 35.

Błąd uszkodzonej rury najprawdopodobniej oznacza przekroczenie limitu czasu. Na przykład zdalna komenda rsync zaczęła obliczać różnice w plikach, ale nie odpowiedziała klientowi na czas.

Jeśli zdarza się to bardzo często, dodaj te ustawienia do lokalnego ~/.ssh/config:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 6

i na zdalnym serwerze (jeśli masz dostęp), skonfiguruj je w /etc/ssh/sshd_config:

ClientAliveInterval 30
ClientAliveCountMax 6

Zobacz: Co oznaczają opcje ServerAliveIntervali co ClientAliveIntervaloznaczają?

Miałem podobny błąd podczas korzystania rsyncz mojego wdrożenia dla Emberaplikacji (ember-cli-deploy). Musiałem poprawnie skonfigurować moje ssh(dodać klucze prywatne do mojego ~/.ssh/)

Wiem, że ten problem jest stary, ale może ktoś (jak ja) nadal ma błąd.

a) Sprawdź, czy usługa ssh jest uruchomiona:

sudo service ssh status

b) Sprawdź połączenie za pomocą trzykrotnego pełnego polecenia:

ssh -vvv <hostname>

c) Być może używasz niewłaściwego klucza ssh lub klucz jest w jakiś sposób uszkodzony.

Wino