我正在使用 ffmpeg 通过网络将视频录制到由 sshfs 挂载的文件系统。我一直遇到这样的问题：如果我的机器进入睡眠状态，ssh 连接就会断开，必须重新连接（我使用-o reconnectsshfs 选项，这样就不会丢失连接）。对于大多数访问文件系统的进程来说，它们似乎甚至没有注意到短暂的断开连接，就好像文件系统只是花了很长时间才达到超时并重新连接。
但是，使用 ffmpeg 时我遇到了一个真正的问题，因为我不仅挂了一会儿，还收到了以下消息：
av_interleaved_write_frame(): Input/output error
然后 ffmpeg 毫不客气地放弃并退出，留下一个无法播放的视频文件！
我尝试了 ffmpeg 的各种选项，例如-reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 4962 -timeout 2000000000。当我尝试这些选项时，行为是相同的，除了单个输入/输出错误之外，它还显示如下消息：
Last message repeated 135 times
Error writing trailer of /sshfs/test.mp4: Input/output error
这一切都发生在很短的时间内，就好像它重试了一些随机次数（我见过最低为 39 次）而中间没有任何延迟。
我不知道问题出在 sshfs 还是 ffmpeg 上，但我需要能够可靠地写入视频，并且不会创建无法播放的视频文件，因为这是在一个定期进入睡眠状态的设备上。我该怎么做？
注意：我发现 Ubuntu 18.04 软件包中的默认 ffmpeg 二进制文件和直接从 ffmpeg.org 下载页面下载的 64 位预编译静态版本 4.2.2 都存在此问题。
更新：我开始认为这是 sshfs 的错误，因为如果我做了类似的事情cat /dev/zero > /sshfs/tmp.mp4并且连接中断，它不会重新连接（由于 cat 正在进行）并且即使它重新连接（因为我尝试另一次访问来戳它重新连接）cat 仍然挂着。
答案1
罪魁祸首是 sshfs，而且该问题不会被解决。
我发现此主题从 12 年前开始，就明确指出这是预期的行为，并且：
This is a limitation of the reconnect in sshfs, which really
wasn't designed to gracefully handle such "hot" reconnects. It's
mostly useful for the case when disconnection happens during no
activity.
由于这不是一个真正的答案（真实的答案会为你的问题提供真正的解决方案，而不是找借口说这是不可能的，这真的不是但没有人足够关心去真正解决这个问题)我将否决我自己的答案。
编辑：好的，我尝试过可以投反对票，但它不让我投反对票。我能理解为什么人们不能给自己的答案投赞成票，但不能理解为什么他们不能投反对票。请有人帮我投反对票。