在詳細模式下通過 SSH 調試 rsync 使用 tee 將標準輸出重定向到日誌文件

我在我們網路上的特定機器上通過 SSH 進行各種 rsync 操作時遇到問題，失敗並給出如下錯誤：

rsync: connection unexpectedly closed (45482 bytes received so far)  [generator]

我發現了一個類似的文章（rsync - unexplained error），其中一個答案建議在詳細模式下執行 rsync 使用的 SSH 命令並重定向輸出，在我的例子中如下：

rsync -av -e 'bash -x -c "ssh -p 22 -vvvv $0 $@ 2>/tmp/rsync-ssh.stderr | tee /tmp/rsync.stdout"' --rsync-path='sudo rsync' "backup_user@10.0.0.2:/media/remote_volume/" "/media/local_volume"

此 rsync 命令似乎可以正常執行一段時間，但最終失敗並出現錯誤：

tee: standard output: Resource temporarily unavailable

我猜它可能會因為以下問題的答案中描述的類似原因而失敗：為什麼這個 tee 失去標準輸出？但是，我似乎不清楚在我的情況下我應該如何更改 SSH 命令來解決問題。

有誰知道在這種情況下使 SSH 與 tee 配合得很好的方法？

在對問題“為什麼這個 tee 失去標準輸出？ ”的答案中討論的解決方案進行了更多閱讀之後，似乎關鍵的變化是用重定向到包含命令的子shell 替換管道，否則該命令將被管道進入。（因此，將：替換command1 | command2為command1 > >( command2 )：）

這樣做的原因是，通過重定向到子shell，而不是直接管道到下一個命令，這是強制子shell 處理返回的任何EAGAIN 錯誤程式碼。正如此 FreeBSD 留言板消息中所討論的：bin/164947：tee 在寫入非阻塞文件描述符時會失去數據（也連結在另一個問題的答案中）tee，並且其他系統二進製文件本身在處理重試方面可能非常糟糕。

對於rsync上面的命令，以下更改似乎解決了我原來的問題：

rsync -av -e 'bash -x -c "ssh -p 22 -vvvv $0 $@ 2>/tmp/rsync-ssh.stderr > >( tee /tmp/rsync.stdout )"' --rsync-path='sudo rsync' "backup_user@10.0.0.2:/media/remote_volume/" "/media/local_volume"

引用自：https://serverfault.com/questions/884876