我使用了rsync多年，从未遇到过如此奇怪的问题：一切正常，除非远程计算机正在运行 Linux Mint 20（尝试了其中 2 个，一个仍在运行 20.1，另一个是全新安装20.2）。无论是单个文件、整个目录还是仅列出资源：rsync协商后立即挂起（无论我“推”还是“拉”）。如果遥控器是 Debian、Armbian，甚至是 Mint 18（我刚刚打开一台旧笔记本电脑来检查），同样的命令也可以正常工作。即使是简单的事情
rsync remote:/path/to/file .
挂起。我尝试了可用的调试选项，发现身份验证（通过 SSH 密钥或密码）一切顺利。如果我输入的密码错误，我会得到正确的“退出”。但是，如果我提供正确的密码/密钥，则在身份验证后，会话将立即挂起，并且不会给出更多线索。我看到的最后一件事是exec request accepted。ps在远程机器上使用显示相应的rsync进程已经生成（是的，在你问之前：通过 SSH 连接到机器工作正常，甚至scp按预期完成其工作 - 只是rsync没有）。
作为最后的手段和解决方法，我rsyncd在远程计算机上启动了一个临时的：
rsync --config=/tmp/rsyncd.conf --daemon --no-detach
然后使用rsync remote::share/path/to/file。虽然这有效并且我完成了当前任务，但我不想每次需要同步某些内容时都重复该操作。
编辑：
人们可能会假设远程的某些输出.bashrc可能会介入：（ssh remotehost /bin/true > out.dat正如手册页建议检查的那样）导致零字节文件，因此这不应该是原因。
strace运行 3 个远程生成的rsync进程（顺便说一句，它们都具有相同的命令行，一个带前导，两个不带前导bash）显示其中 2 个以 结尾wait4(-1,，另一个以{tv_sec=32, tv_usec=23154}.正如预期的那样， “客户端”（rsync由用户调用）也显示一个wait4(-1,，因为它很可能等待远程端响应。
任何想法可能是什么罪魁祸首，如何解决这个问题，甚至如何进一步缩小范围？至于调试，我已经使用过rsync --debug=all4 -avve "ssh -vvv" …，这就是我所描述的方式。
作为参考，rsyncd.conf上述解决方法中使用的：
使用 chroot = true 主机允许= 192.168.0.0/24 传输日志记录 = true 日志文件= /tmp/rsyncd.log 日志格式 = %h %o %f %l %b [分享] 评论=分享 路径=/mnt/共享 只读 = 否 列表 = 是 uid = 无人 gid = 无组
答案1
在我无法使用第三台 Mint20 机器重现该问题后，我找到了罪魁祸首。事实证明，只有当其中一台 Mint20 机器作为“服务器”参与时才会发生这种情况，从而缩小了搜索范围。跑到which rsync那里并得到了/usr/local/bin/rsync回来。这（与“服务器”端显示的第四个 rsync 进程一起，我忽略了它，因为我认为它属于我定期运行的其他操作）让我步入正轨：
/usr/local/bin/rsync被安排围绕一个工作同步错误这是自 2006 年以来已知的（并且仍未修复；找到脚本在这里）。虽然多年来它很好地解决了这个令人讨厌的问题，因为该机器仅用作客户端，但现在需要更换该机器，并且为了传输而充当服务器，但它适得其反。
为了解决最初的问题以及当前的问题，我将脚本移动到仅在PATH活动用户的目录中，但是不是 root（远程rsync总是由 root 生成，并且应该获得原始的/usr/bin/rsync）。经过各个方向的测试，似乎有效（只需要等待我应用了原始解决方法的“那个 cron 作业”）。
PS：对于那些rsync-no-vanished也使用该脚本的人来说，稍作调整即可解决该问题。只需将脚本更改为：
if [[ $(id -u) -eq 0 ]]; then
/usr/bin/rsync $@
else
# original "rsync-no-vanished" script in here
fi
这样，当由根（例如生成的遥控器）调用时，它仅引用原始rsync二进制文件，并且仅使用客户端调用的“解决方法”。
附：在联系项目并提供详细信息和建议的修复后，脚本很快更新了这样以后就可以避免类似的情况了（感谢韦恩的及时回复！）。